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

[Jürgen Groß <jgross@xxxxxxxx>]

On 28.11.19 12:19, Jan Beulich wrote:
> 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.
Assuming an Ack: in a timely manner:

Release-acked-by: Juergen Gross <jgross@xxxxxxxx>


Juergen

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