On 6/20/25 06:53, Kirill A. Shutemov wrote:
> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index 463b784499a8..94c335229697 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -825,11 +825,24 @@ static void __init __efi_enter_virtual_mode(void)
>
> efi_sync_low_kernel_mappings();
>
> + /*
> + * set_virtual_address_map is the only service located at lower
> + * addresses, so we have to temporarily disable LASS around it.
> + * Note that clearing EFLAGS.AC is not enough for this, the whole
> + * LASS needs to be disabled.
> + */
> + if (cpu_feature_enabled(X86_FEATURE_LASS))
> + cr4_clear_bits(X86_CR4_LASS);
Could we do it like this instead?
unsigned long lass = cr4_read_shadow() & X86_FEATURE_LASS;
...
cr4_clear_bits(lass);
> status = efi_set_virtual_address_map(efi.memmap.desc_size * count,
> efi.memmap.desc_size,
> efi.memmap.desc_version,
> (efi_memory_desc_t *)pa,
> efi_systab_phys);
> +
> + if (cpu_feature_enabled(X86_FEATURE_LASS))
> + cr4_set_bits(X86_CR4_LASS);
and:
cr4_set_bits(lass);
> if (status != EFI_SUCCESS) {
> pr_err("Unable to switch EFI into virtual mode (status=%lx)!\n",
> status);
That way, neither the presence of X86_FEATURE_LASS nor the ordering of
setting up X86_CR4_LASS matters.
Let's say the CPU supports X86_FEATURE_LASS and this code gets called
before the kernel is ready for LASS. It would break as written above.
