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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> 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).

Of course in our case pt timer is edge-interrupt, which shouldn't trigger
such multi-reads issue in real hardware.  But anyway it's not a good behavior
to change RTE vector w/o stopping the interrupt source first...

Thanks
Kevin

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