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

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

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Friday, March 24, 2017 4:18 PM
> 
> >>> 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?
> 

It's read-only to software, but cleared only when accepting EOI.

Thanks
Kevin

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