[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f6d16f82-9cbe-993d-88aa-1644e89c4fe7@intel.com>
Date: Thu, 12 Jan 2023 17:17:53 -0800
From: Sohil Mehta <sohil.mehta@...el.com>
To: Dave Hansen <dave.hansen@...el.com>,
Yian Chen <yian.chen@...el.com>,
<linux-kernel@...r.kernel.org>, <x86@...nel.org>,
Andy Lutomirski <luto@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ravi Shankar <ravi.v.shankar@...el.com>,
Tony Luck <tony.luck@...el.com>,
Paul Lai <paul.c.lai@...el.com>
Subject: Re: [PATCH 5/7] x86/cpu: Enable LASS (Linear Address Space
Separation)
On 1/12/2023 10:17 AM, Dave Hansen wrote:
> In the end, want X86_CR4_LASS set when the kernel wants LASS and clear
> in *ALL* other cases. That would be simply:
>
> if (cpu_feature_enabled(X86_FEATURE_LASS)) {
> cr4_set_bits(X86_CR4_LASS);
> } else {
> cr4_clear_bits(X86_CR4_LASS);
> }
>
Thanks for the explanation. This is very helpful.
> I'm also wondering if we even want a Kconfig option. Is anyone
> realistically going to be compiling this support out?
I was initially thinking we should leave the Kconfig option for users
that really *need* vsyscall support. But, thinking about it more, we
don't need an LASS Kconfig option for that.
We can make CONFIG_LEGACY_VSYSCALL_NONE as the default instead of the
current CONFIG_LEGACY_VSYSCALL_XONLY. The kernel can disable LASS at
boot time if a user/admin has shown explicit preference by selecting
CONFIG_LEGACY_VSYSCALL_XONLY or by providing command line parameter
vsyscall=xonly/emulate.
Thoughts?
Powered by blists - more mailing lists