Re: [Xen-devel] x86: adjust handling of interrupts coming in via legacy vectors

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.05.12 at 17:35, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 14/05/2012 13:39, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> The debugging code added in c/s 24707:96987c324a4f was hit a (small)
>> number of times (one report being
>> http://lists.xen.org/archives/html/xen-devel/2012-05/msg00332.html),
>> apparently always with a vector within the legacy range. Obviously,
>> besides legacy vectors not normally expected to be in use on systems
>> with IO-APIC(s), they should never make it to the IRQ migration logic.
>> 
>> This wasn't being prevented so far: Since we don't have a one-to-one
>> mapping between vectors and IRQs - legacy IRQs may have two vectors
>> associated with them (one used in either 8259A, the other used in one
>> of the IO-APICs) -, vector-to-IRQ translations for legacy vectors (as
>> used in do_IRQ()) would yield a valid IRQ number despite the IRQ
>> really being handled via an IO-APIC.
>> 
>> This gets changed here - disable_8259A_irq() zaps the legacy vector-to-
>> IRQ mapping, and enable_8259A_irq(), should it ever be called for a
>> particular interrupts, restores it.
>> 
>> Additionally, the spurious interrupt logic in do_IRQ() gets adjusted
>> too: Interrupts coming in via legacy vectors obviously didn't get
>> reported through the IO-APIC/LAPIC pair (as we never program these
>> vectors into any RTE), and hence shouldn't get ack_APIC_irq() called on
>> them. Instead, a new function (pointer) bogus_8259A_irq() gets used to
>> have the 8259A driver take care of the bogus interrupt (as outside of
>> automatice EOI mode it may need an EOI to be issued for it to prevent
>> other interrupts that may legitimately go through the 8259As from
>> getting masked out).
>> 
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> Looks sensible, and I suppose good to have for 4.2.
> 
> Acked-by: Keir Fraser <keir@xxxxxxx>

Please take a look at the v2 I just sent, to accommodate a suggestion
from Andrew Cooper.

Jan


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