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
