Re: [RFC PATCH 05/13] x86/irq: Reserve a user IPI notification vector

[Sohil Mehta]

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