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

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

> From: Tian, Kevin
> Sent: Friday, March 24, 2017 4:26 PM
> 
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Friday, March 24, 2017 4:18 PM
> >
> > >>> On 24.03.17 at 08:48, <kevin.tian@intel.com> wrote:
> > >>  From: Jan Beulich [mailto:JBeulich@suse.com]
> > >> 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.
> 

btw it's also the reason why we set EOI exit bitmap for level-triggered
interrupt in APICv, to allow proper emulation of above behavior. :-)

Thanks
Kevin

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