Re: [Xen-devel] IRQ: issues with directed EOI and IO-APIC ack methods

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.02.12 at 17:53, Keir Fraser <keir@xxxxxxx> wrote:
> On 13/02/2012 16:03, "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx> wrote:
>> The pcpu LAPICs support EOI Broadcast suppression and Xen enabled it.
>> In arch/x86/apic.c:verify_local_APIC, there is a comment stating that
>> directed EOI support must use the old IO-APIC ack method.

The reason is that with this LAPIC feature you want to send the ack
to the LAPIC immediately (mask_and_ack_level_ioapic_irq()), which
matched the old method.

With the various conditionals there and in end_level_ioapic_irq() it
may be a good first step to create three distinct hw_irq_controller
instances (old, new, and "directed EOI") for level triggered interrupts,
and have them do just what is needed for the specific case. Then it
may become easier to spot what's going wrong.

> Well, it's not surprising that some systems won't like this method. Firstly,
> calling the LAPIC feature 'directed EOI' is misleading. The feature is 'EOI
> broadcast suppression' -- specifically, EOI to the LAPIC does not cause EOI
> to the IO-APIC, instead the IO-APIC has to be manually EOIed as a separate
> operation.
> 
> Now, not all IO-APICs directly support this. See io_apic.c:__io_apic_eoi()
> -- if the IO-APIC does not have an EOI register, then an EOI is forced in a
> slightly gross way. I wonder how reliable that is across a broad range of
> chipsets; reliable enough to rely on it for *every* interrupt? ;-)

With the EOI register pre-dating this mis-named CPU feature, I
wouldn't expect anyone to have built a system with CPU(s) this new
but an old chipset. But it's certainly worth verifying the IO-APIC
version on the affected system(s).

> Cc'ing the patch author Edwin Zhai. If it can't be resolved with Intel, I'm
> personally quite happy to see the original patch reverted.

Let's rather try understanding the issue than reverting something that
ought to help performance.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel