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

In 5655ce8b1e ("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>
This commit is contained in:
Jan Beulich committed 2019-12-27 09:53:35 +01:00
1 parent 189da94865
commit 53fd9dafeb
1 file changed
+6 -11
+6 -11
View File
@@ -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:
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.