Re: [Xen-devel] [PATCH] x86/IRQ: make internally used IRQs also honor the pending EOI stack

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.11.2019 12:03, Jan Beulich wrote:
> At the time the pending EOI stack was introduced there were no
> internally used IRQs which would have the LAPIC EOI issued from the
> ->end() hook. This had then changed with the introduction of IOMMUs,
> but the interaction issue was presumably masked by
> irq_guest_eoi_timer_fn() frequently EOI-ing interrupts way too early
> (which got fixed by 359cf6f8a0ec ["x86/IRQ: don't keep EOI timer
> running without need"]).
> 
> The problem is that with us re-enabling interrupts across handler
> invocation, a higher priority (guest) interrupt may trigger while
> handling a lower priority (internal) one. The EOI issued from
> ->end() (for ACKTYPE_EOI kind interrupts) would then mistakenly
> EOI the higher priority (guest) interrupt, breaking (among other
> things) pending EOI stack logic's assumptions.
> 
> Notes:
> 
> - In principle we could get away without the check_eoi_deferral flag.
>   I've introduced it just to make sure there's as little change as
>   possible to unaffected paths.
> - Similarly the cpu_has_pending_apic_eoi() check in do_IRQ() isn't
>   strictly necessary.
> - The new function's name isn't very helpful with its use in
>   end_level_ioapic_irq_new(). I did also consider eoi_APIC_irq() (to
>   parallel ack_APIC_irq()), but then liked this even less.
> - Other than I first thought serial console IRQs shouldn't be
>   affected, as we run them on specifically allocated high priority
>   vectors.
> 
> Reported-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
> Diagnosed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

In case it's not explicit enough from the description: While the
issue appears to be long standing, it looks to have been masked
by other shortcomings prior to 4.13. Therefore this should be
considered at least a perceived regression, even if it may not
strictly be one.

Jan

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