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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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.

Thanks, Roger.

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