Re: [PATCH v2 1/3] x86/cpu: Defer LASS enabling until userspace comes up

[Sohil Mehta]

On 1/20/2026 3:47 PM, Sohil Mehta wrote:

> +/*
> + * Finalize features that need to be enabled just before entering
> + * userspace. Note that this only runs on a single CPU. Use appropriate
> + * callbacks if all the CPUs need to reflect the same change.
> + */
> +static int cpu_finalize_pre_userspace(void)
> +{
> +	if (!cpu_feature_enabled(X86_FEATURE_LASS))
> +		return 0;
> +
> +	/* Runs on all online CPUs and future CPUs that come online. */
> +	cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "x86/lass:enable", enable_lass, NULL);
> +
> +	return 0;
> +}
> +late_initcall(cpu_finalize_pre_userspace);
> +

@Dave, Nikunj,

The current patch
	https://lore.kernel.org/lkml/1bc0b798-9cef-4dfd-af06-7674b699af1b@xxxxxxxxx/

..to defer CR pinning enforcement until CPU online makes sense for the
FRED fix. Eventually, I am thinking we can defer CR pinning even further
until userspace comes up.

setup_cr_pinning(), which enables the static key, can be moved to a
late_initcall() such as above. The cpu_online() check to enforce CR
pinning would still be needed to make it play nice with CPU hotplug.

Do you see an issue with that approach?

>  /* These bits should not change their value after CPU init is finished. */
>  static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP |
>  					     X86_CR4_FSGSBASE | X86_CR4_CET | X86_CR4_FRED;