On Fri, Sep 24 2021 at 01:07, Thomas Gleixner wrote:
On Mon, Sep 13 2021 at 13:01, Sohil Mehta wrote:
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?
Let's see how this works:
task starts using UINTR. set UINTR_NOTIFACTION_VECTOR in MSR_IA32_UINTR_MISC
So from that point on the User-Interrupt Notification Identification mechanism swallows the vector.
Where this stops working is not limited to context switch. The wreckage comes from XSAVES:
"After saving the user-interrupt state component, XSAVES clears UINV. (UINV is IA32_UINTR_MISC[39:32]; XSAVES does not modify the remainder of that MSR.)"
So the problem is _not_ context switch. The problem is XSAVES and that can be issued even without a context switch.
The obvious question is: What is the value of clearing UINV?
Absolutely none. That notification vector cannot be used for anything else, so why would the OS be interested to see it ever? This is about user space interupts, right?
UINV should be set _ONCE_ when CR4.UINTR is enabled and not be touched by XSAVES/XRSTORS at all. Any delivery of this vector to the OS should be considered a hardware bug.
Thanks,
tglx