Re: [Xen-devel] Interrupt injection with ISR set on Intel hardware

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

> From: Roger Pau Monné [mailto:roger.pau@xxxxxxxxxx]
> Sent: Wednesday, November 28, 2018 5:20 PM
> 
> On Thu, Nov 01, 2018 at 09:18:14AM +0000, Andrew Cooper wrote:
> > On 01/11/2018 00:40, Tian, Kevin wrote:
> > >> From: Tian, Kevin
> > >> Sent: Tuesday, October 30, 2018 3:00 PM
> > >>
> > >>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > >>> Sent: Thursday, October 25, 2018 9:58 PM
> > >>>
> > >>>>>> On 25.10.18 at 15:02, <andrew.cooper3@xxxxxxxxxx> wrote:
> > >>>> On 25/10/18 13:51, Jan Beulich wrote:
> > >>>>>>>> On 15.10.18 at 14:06, <andrew.cooper3@xxxxxxxxxx> wrote:
> > >>>>>> From the debugging, we see that PPR/IRR/ISR appear to retain
> their
> > >>> state
> > >>>>>> across the mwait, and there is nothing in the manual which I can
> see
> > >>>>>> discussing the interaction of LAPIC state and C states.
> > >>>>> Is it perhaps a bad idea to go idle with an un-acked interrupt?
> > >>>> Most likely.
> > >>>>
> > >>>> Then again, going idle with an un-acked line interrupt does appear
> to
> > >>>> work.  It is only un-acked edge interrupts which appear to hit this
> issue.
> > >>> Well, non-maskable MSI are the only ones (outside of "new" IO-APIC
> > >>> ack mode, which should not be used on recent hardware because of
> > >>> directed EOI presumably being available everywhere) where the ack
> > >>> gets deferred until the .end hook (i.e. after the handler was run).
> > >>> IOW AFAICT line interrupts would never be pending when we go idle.
> > >>>
> > >>>> Still - I'd prefer some guidance from the hardware folk as to what
> can
> > >>>> realistically be expected here.
> > >>> Fully agree.
> > >> Just sent a mail internally to get clarification.
> > >>
> > > One question.
> > >
> > > in the first mail, Roger mentioned:
> > > --
> > > The issue is caused by what seems to be an interrupt injection while
> > > Xen is still servicing a previous interrupt (ie: the interrupt hasn't
> > > been EOI'ed and ISR for the vector is set) with **the same or lower
> > > priority** than the interrupt currently being serviced.
> > > --
> > >
> > > from the debug log, it's actually the exact same vector (0x21) as
> > > what is being in service in peoi stack.
> >
> > Yes - the problem is a repeat delivery of an interrupt which Xen thinks
> > it is already in the middle of processing.
> >
> > >
> > > Do you actually see the scenario "with the same or lower priority"?
> > > If yes, can you post the debug log too?
> >
> > I'm afraid that I don't understand the question.  A repeat delivery of
> > vector 0x21 is the same priority.
> >
> > I haven't seen an example of a lower priority interrupt being accepted,
> > but that might just be down to the repro scenario.  Unfortunately, XTF
> > isn't usable on native hardware yet so I can't experiment cleanly in
> > this area.
> 
> Hello,
> 
> Is there any news on this?
> 
> I would like to have a fix before the 4.12 release if possible.
> 

sorry still waiting for a formal clarification from internal team...

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel