On 9/23/2021 4:07 PM, Thomas Gleixner wrote:
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?
This didn't get covered in the other thread. Thought, I would clarify this a bit more.
A notification IPI is sent from the CPU that executes SENDUIPI if the target task is running (SN is 0).
If the target task is not running SN bit in the UPID is set, which prevents any notification interrupts from being generated.
However, it is possible that SN is 0 when SENDUIPI was executed which generates the notification IPI. But when the IPI arrives on receiver CPU, SN has been set, the task state has been saved and UINV has been cleared.
A kernel interrupt is detected in this case. I have a sample that demos this. I'll fix the current code and then send out the results.
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?
You covered this in the other thread.
+#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.
Will fix this.
Thanks,
Sohil