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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

>> Quite possibly that's not something an ordinary OS would do.
> 
> This is definitely not something an ordinary OS would do during normal
> operation.  Xen suffers more than most other hypervisors because our
> device drivers are in dom0.
> 
> That said, can't we just mask the line at the PIC/IO-APIC and forgo the
> PEOI stack entirely?  The more I think about how our interrupt handling
> works, the more I think vastly over complicated.

MSIs obviously can't be masked at the PIC/IO-APIC; we do
mask (level) IO-APIC IRQs already (when directed EOI is not in
use). As to avoiding the PEOI stack - perhaps with directed EOI
we could, as the strict ordering of EOIs then is not a requirement.

Jan



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