Messages in this thread | | | Date | Thu, 12 Jan 2023 10:17:11 -0800 | Subject | Re: [PATCH 5/7] x86/cpu: Enable LASS (Linear Address Space Separation) | From | Dave Hansen <> |
| |
On 1/9/23 21:52, Yian Chen wrote: > +static __always_inline void setup_lass(struct cpuinfo_x86 *c) > +{ > + if (cpu_feature_enabled(X86_FEATURE_LASS)) { > + cr4_set_bits(X86_CR4_LASS); > + } else { > + /* > + * only clear the feature and cr4 bits when hardware > + * supports LASS, in case it was enabled in a previous > + * boot (e.g., via kexec) > + */ > + if (cpu_has(c, X86_FEATURE_LASS)) { > + cr4_clear_bits(X86_CR4_LASS); > + clear_cpu_cap(c, X86_FEATURE_LASS); > + } > + } > +}
Could you try testing this, please?
Please remember that there are three things in play here: 1. disabled-features.h. Makes cpu_feature_enabled(X86_FEATURE_LASS)==0 when CONFIG_X86_LASS=n. 2. The X86_FEATURE_LASS software feature bit itself. clearcpuid=lass would clear it. 3. The actual CPU enumeration of X86_FEATURE_LASS
The else{} is handling the case where X86_FEATURE_LASS is compiled out but where the CPU supports LASS. It doesn't do anything when the CPU lacks LASS support *OR* when clearcpuid=lass is used.
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); }
The cr4_clear_bits(X86_CR4_LASS) should be safe regardless of CPU or kernel support for LASS.
As for the:
clear_cpu_cap(c, X86_FEATURE_LASS);
It really only matters for kernels where CONFIG_X86_LASS=n but where the CPU supports it. I'm not clear on what specifically you expect to gain from it, though.
I'm also wondering if we even want a Kconfig option. Is anyone realistically going to be compiling this support out?
| |