On Mon, Sep 13 2021 at 13:01, Sohil Mehta wrote:
A user interrupt notification vector is used on the receiver's cpu to identify an interrupt as a user interrupt (and not a kernel interrupt). Hardware uses the same notification vector to generate an IPI from a sender's cpu core when the SENDUIPI instruction is executed.
Typically, the kernel shouldn't receive an interrupt with this vector. However, it is possible that the kernel might receive this vector.
Scenario that can cause the spurious interrupt:
Step cpu 0 (receiver task) cpu 1 (sender task)
1 task is running 2 executes SENDUIPI 3 IPI sent 4 context switched out 5 IPI delivered (kernel interrupt detected)
A kernel interrupt can be detected, if a receiver task gets scheduled out after the SENDUIPI-based IPI was sent but before the IPI was delivered.
What happens if the SENDUIPI is issued when the target task is not on the CPU? How is that any different from the above?
The kernel doesn't need to do anything in this case other than receiving the interrupt and clearing the local APIC. The user interrupt is always stored in the receiver's UPID before the IPI is generated. When the receiver gets scheduled back the interrupt would be delivered based on its UPID.
So why on earth is that vector reaching the CPU at all?
+#ifdef CONFIG_X86_USER_INTERRUPTS
- seq_printf(p, "%*s: ", prec, "UIS");
No point in printing that when user interrupts are not available/enabled on the system.
- for_each_online_cpu(j)
seq_printf(p, "%10u ", irq_stats(j)->uintr_spurious_count);- seq_puts(p, " User-interrupt spurious event\n");
#endif return 0; } @@ -325,6 +331,33 @@ DEFINE_IDTENTRY_SYSVEC_SIMPLE(sysvec_kvm_posted_intr_nested_ipi) } #endif +#ifdef CONFIG_X86_USER_INTERRUPTS +/*
- Handler for UINTR_NOTIFICATION_VECTOR.
- The notification vector is used by the cpu to detect a User Interrupt. In
- the typical usage, the cpu would handle this interrupt and clear the local
- apic.
- However, it is possible that the kernel might receive this vector. This can
- happen if the receiver thread was running when the interrupt was sent but it
- got scheduled out before the interrupt was delivered. The kernel doesn't
- need to do anything other than clearing the local APIC. A pending user
- interrupt is always saved in the receiver's UPID which can be referenced
- when the receiver gets scheduled back.
- If the kernel receives a storm of these, it could mean an issue with the
- kernel's saving and restoring of the User Interrupt MSR state; Specifically,
- the notification vector bits in the IA32_UINTR_MISC_MSR.
Definitely well thought out hardware that.
Thanks,
tglx