Re: [Xen-devel] cpuidle and un-eoid interrupts at the local apic

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.05.13 at 22:32, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> Xen has been woken up by an interrupt of vector 0x27, but has a vector
> 0x2f on the top of the pending EOI stack for the local APIC.
> 
> I have put in more debugging to dump the LAPIC state of the two
> interesting vectors and the IOAPIC state, but I have no idea if/when the
> problem might reoccur. 
> 
> My understanding of LAPIC priority leads me to think that Xen really
> shouldn't be woken up by a lower priority vector if a higher priority
> one is still un-eoi'd.  There is not yet sufficient information to tell
> whether this is truely the case, or that Xen has simply gotten confused
> about which vectors it eoi'd.

Considering that this was on a Haswell, and got so far not reported
by anyone else, I wonder whether that's related to some effect of
(or flaw in) APIC virtualization. But of course without knowing the
state of the LAPIC, that's hard to tell for sure. The more that a stray
ack_APIC_irq() could lead to the same effect, and that EDX (holding
"sp") has a value of 4 - quite a few lower priority vectors awaiting
an EOI considering that vector group 2x is the lowest possible one
(i.e. the other entries on the stack ought to have even larger
vector numbers).

> Having said that, we do keep line level interrupts un-eoi'd for extended
> periods while guests service the interrupt.  Given that vectors are
> chosen at random, we could get into a situation where a line interrupt
> has a vector 0xdf and stays pending for 150ms (which I measured as a
> not-overly-uncommon mean-time-till-eoi for line level interrupt).  This
> would starve any other guest interrupts for an extended period.
> 
> Given directed-eoi support in the past few generations of processor, the
> requirement for the pending EOI stack has disappeared as far as I am
> aware.  Would it be sensible idea in general to make use of the pending
> eoi stack conditional on not having/using directed EOI support?

We don't use ACKTYPE_EOI in that case: setup_IO_APIC() only sets
ioapic_level_type.ack to irq_complete_move (consumed by
pirq_acktype()) when ioapic_ack_new, and directed EOI implies
!ioapic_ack_new (see verify_local_APIC()). The only other case of
using ACKTYPE_EOI is for non-maskable MSIs.

Jan


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