Re: [PATCH v6 05/10] x86/sme: Avoid SME/SVE related checks on non-SME/SVE platforms

[Tom Lendacky]

On 2/27/24 08:55, Ard Biesheuvel wrote:
> On Mon, 26 Feb 2024 at 22:38, Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
> > On 2/26/24 08:29, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel <ardb@xxxxxxxxxx>

> > > -void __init sme_enable(struct boot_params *bp)
> > > +void __head sme_enable(struct boot_params *bp)
> > >    {
> > >        const char *cmdline_ptr, *cmdline_arg, *cmdline_on;
> > >        unsigned int eax, ebx, ecx, edx;
> > >        unsigned long feature_mask;
> > >        unsigned long me_mask;
> > >        char buffer[16];
> > > -     bool snp;
> > >        u64 msr;
> > >
> > > -     snp = snp_init(bp);
> >
> > The snp_init() call is here because the SNP CPUID table needs to be
> > established before the below CPUID instruction is executed. This can't be
> > moved.
>
> Yeah, good point. I didn't spot this in my SEV-SNP boot testing,
> presumably because the firmware's VC handler is still active in my
> case, but this isn't guaranteed, e.g., when booting via the
> decompressor, or when using 5-level paging.

Actually, the kernel's do_vc_no_ghcb() is the handler that gets invoked. 
Since the CPUID table is not initialized, -EOPNOTSUPP is returned from 
snp_cpuid(), which results in the handler using the MSR protocol to get 
the CPUID information from the hypervisor - which we don't want for SNP in 
this situation.

Thanks,
Tom


> Thanks for the review.