On Wed, Jul 10, 2024 at 07:06:43PM +0300, Alexander Shishkin wrote: > In order to map the EFI runtime services, set_virtual_address_map > needs to be called, which resides in the lower half of the address > space. This means that LASS needs to be temporarily disabled around > this call. This can only be done before the CR pinning is set up. > > Move CR pinning setup behind the EFI initialization. > > Signed-off-by: Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> > Suggested-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> So the previous patch makes us not boot, and this fixes it up? Perhaps order things differently? > --- > arch/x86/kernel/cpu/common.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c > index 8aa621dc7d30..c93c59a27dfa 100644 > --- a/arch/x86/kernel/cpu/common.c > +++ b/arch/x86/kernel/cpu/common.c > @@ -1948,7 +1948,6 @@ static __init void identify_boot_cpu(void) > enable_sep_cpu(); > #endif > cpu_detect_tlb(&boot_cpu_data); > - setup_cr_pinning(); > > tsx_init(); > tdx_init(); > @@ -2367,10 +2366,16 @@ void __init arch_cpu_finalize_init(void) > > /* > * This needs to follow the FPU initializtion, since EFI depends on it. > + * It also needs to precede the CR pinning setup, because we need to be > + * able to temporarily clear the CR4.LASS bit in order to execute the > + * set_virtual_address_map call, which resides in lower addresses and > + * would trip LASS if enabled. > */ > if (efi_enabled(EFI_RUNTIME_SERVICES)) > efi_enter_virtual_mode(); > > + setup_cr_pinning(); > + > /* > * Ensure that access to the per CPU representation has the initial > * boot CPU configuration. > -- > 2.43.0 >
