Re: Interrupt injection with ISR set on Intel hardware

From: "Tian, Kevin" <kevin.tian@intel.com>
To: 'Jan Beulich' <JBeulich@suse.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Wei Liu <wei.liu2@citrix.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: Interrupt injection with ISR set on Intel hardware
Date: Thu, 1 Nov 2018 00:40:55 +0000	[thread overview]
Message-ID: <AADFC41AFE54684AB9EE6CBC0274A5D19BE33974@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D19BE2BAB0@SHSMSX101.ccr.corp.intel.com>

> From: Tian, Kevin
> Sent: Tuesday, October 30, 2018 3:00 PM
> 
> > From: Jan Beulich [mailto:JBeulich@suse.com]
> > Sent: Thursday, October 25, 2018 9:58 PM
> >
> > >>> On 25.10.18 at 15:02, <andrew.cooper3@citrix.com> wrote:
> > > On 25/10/18 13:51, Jan Beulich wrote:
> > >>>>> On 15.10.18 at 14:06, <andrew.cooper3@citrix.com> 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.

Do you actually see the scenario "with the same or lower priority"?
If yes, can you post the debug log too?

Thanks
Kevin

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