Re: [Xen-devel] [xen-unstable test] 106504: regressions - FAIL

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 24.03.17 at 08:48, <kevin.tian@xxxxxxxxx> wrote:
>>  From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Wednesday, March 22, 2017 8:48 PM
>> 
>> > 3. We read RTE 3 times. 1st happens when we set vIRR. 2nd happens when
>> > pt_update_irq() returns. 3rd happens in pt_intr_post(). If guest
>> > changes the vector in RTE during the window, it will also incur losing
>> > or getting more periodic timer interrupt.
>> 
>> Which raises the question whether latching the value read the first time
>> would address the issue you demonstrate with the test case.
>> Or alternatively deferring writes to take effect only once readers are done
>> with their perhaps multiple accesses?
>> 
>> Can you get in touch with your chipset folks to find out whether hardware
>> has cases where multiple reads occur during the processing of a single 
> event?
>> 
> 
> There is a similar case. For level-triggered interrupt, there is a "remote 
> IRR"
> bit in RTE which is set to 1 when LAPIC accepts the level interrupt sent by 
> IOAPIC.  It's then cleared by EOI broadcast from LAPIC later, based on 
> matching interrupt vectors. If software happens to change the vector of 
> the said RTE in-between, "remote IRR" bit will never be cleared (it 
> expects an EOI with new vector now while actual EOI for previous injection
> contains old vector).

Hmm, I'd expect such a write to clear IRR at once, if somebody
really wrote code this way. Or is the bit wrongly documented R/W?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel