On 9/23/2021 3:24 PM, Thomas Gleixner wrote:
On Mon, Sep 13 2021 at 13:01, Sohil Mehta wrote:
SENDUIPI is a special ring-3 instruction that makes a supervisor mode
memory access to the UPID and UITT memory. Currently, KPTI needs to be
off for User IPIs to work. Processors that support user interrupts are
not affected by Meltdown so the auto mode of KPTI will default to off.
Users who want to force enable KPTI will need to wait for a later
version of this patch series that is compatible with KPTI. We need to
allocate the UPID and UITT structures from a special memory region that
has supervisor access but it is mapped into userspace. The plan is to
implement a mechanism similar to LDT.
Seriously?
Are questioning why we should add KPTI support if the hardware is not
affected by Meltdown?
or
Why use an LDT like mechanism to do this?
I have listed this as one of the opens in the cover letter as well. I am
not sure if users who force enable PTI would really care about User
Interrupts.
Any input here would be helpful.
+ if (!cpu_feature_enabled(X86_FEATURE_UINTR))
+ goto disable_uintr;
+
+ /* checks the current processor's cpuid bits: */
+ if (!cpu_has(c, X86_FEATURE_UINTR))
+ goto disable_uintr;
+
+ /*
+ * User Interrupts currently doesn't support PTI. For processors that
+ * support User interrupts PTI in auto mode will default to off. Need
+ * this check only for users who have force enabled PTI.
+ */
+ if (boot_cpu_has(X86_FEATURE_PTI)) {
+ pr_info_once("x86: User Interrupts (UINTR) not enabled. Please disable PTI using 'nopti' kernel parameter\n");
That message does not make sense. The admin has explicitly added 'pti'
to the kernel command line on a CPU which is not affected. So why would
he now have to add 'nopti' ?
Yup. I'll fix this and other issues in this patch.
I thought the user should know why UINTR has been disabled. In
hindsight, this would have been better covered in the sample Readme or
something similar.
Thanks,
Sohil
