Messages in this thread | | | Subject | Re: [PATCH v3 5/8] x86/sme: Replace occurrences of sme_active() with cc_platform_has() | From | Tom Lendacky <> | Date | Tue, 21 Sep 2021 12:04:58 -0500 |
| |
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. >
| |