Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has()

[Tom Lendacky]

On 9/20/21 2:23 PM, Kirill A. Shutemov wrote:
> On Wed, Sep 08, 2021 at 05:58:36PM -0500, Tom Lendacky wrote:
> > diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_identity.c
> > index 470b20208430..eff4d19f9cb4 100644
> > --- a/arch/x86/mm/mem_encrypt_identity.c
> > +++ b/arch/x86/mm/mem_encrypt_identity.c
> > @@ -30,6 +30,7 @@
> >   #include <linux/kernel.h>
> >   #include <linux/mm.h>
> >   #include <linux/mem_encrypt.h>
> > +#include <linux/cc_platform.h>
> >   
> >   #include <asm/setup.h>
> >   #include <asm/sections.h>
> > @@ -287,7 +288,7 @@ void __init sme_encrypt_kernel(struct boot_params *bp)
> >   	unsigned long pgtable_area_len;
> >   	unsigned long decrypted_base;
> >   
> > -	if (!sme_active())
> > +	if (!cc_platform_has(CC_ATTR_HOST_MEM_ENCRYPT))
> >   		return;
> >   
> >   	/*
>
> This change break boot for me (in KVM on Intel host). It only reproduces
> with allyesconfig. More reasonable config works fine, but I didn't try to
> find exact cause in config.

Looks like instrumentation during early boot. I worked with Boris offline 
to exclude arch/x86/kernel/cc_platform.c from some of the instrumentation 
and that allowed an allyesconfig to boot.

Thanks,
Tom

> Convertion to cc_platform_has() in __startup_64() in 8/8 has the same
> effect.
>
> I believe it caused by sme_me_mask access from __startup_64() without
> fixup_pointer() magic. I think __startup_64() requires special treatement
> and we should avoid cc_platform_has() there (or have a special version of
> the helper). Note that only AMD requires these cc_platform_has() to return
> true.