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 <jbeul...@suse.com>
---
TBD: In the end I'm not sure this is really worth it then.
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -1991,18 +1991,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:
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
