x86/IRQ: simplify pending EOI stack logic for internally used IRQs

In 5655ce8b1ec2 ("x86/IRQ: make internally used IRQs also honor the
pending EOI stack") it was mentioned that both the check_eoi_deferral
per-CPU variable and the cpu_has_pending_apic_eoi() were added just to
have as little impact on existing behavior as possible, to reduce the
risk of a last minute regression in 4.13.

Upon closer inspection, dropping the variable is an option only if all
callers of ->end() would assume the responsibility of also calling
flush_ready_eoi(). Therefore only drop the cpu_has_pending_apic_eoi()
guard now.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 03e2f8edb62ca466537cb0acb7549ce25b1ef35b..9adad3ff04ae5ce2756ea5b2fdab7c71f97dd085 100644 (file)
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1990,18 +1990,13 @@ void do_IRQ(struct cpu_user_regs *regs)
          * If higher priority vectors still have their EOIs pending, we may
          * not issue an EOI here, as this would EOI the highest priority one.
          */
-        if ( cpu_has_pending_apic_eoi() )
-        {
-            this_cpu(check_eoi_deferral) = true;
-            desc->handler->end(desc, vector);
-            this_cpu(check_eoi_deferral) = false;
-
-            spin_unlock(&desc->lock);
-            flush_ready_eoi();
-            goto out_no_unlock;
-        }
-
+        this_cpu(check_eoi_deferral) = true;
         desc->handler->end(desc, vector);
+        this_cpu(check_eoi_deferral) = false;
+
+        spin_unlock(&desc->lock);
+        flush_ready_eoi();
+        goto out_no_unlock;
     }
 
  out_no_end: