From: Michael Kelley (LINUX) <mikelley@xxxxxxxxxxxxx> > > From: Borislav Petkov <bp@xxxxxxxxx> Sent: Friday, March 24, 2023 8:49 AM > > > > On Thu, Mar 23, 2023 at 02:43:06PM +0100, Borislav Petkov wrote: > > > Ok, lemme queue 1-2,4-6 as previously mentioned. > > > > With first six applied: > > > > arch/x86/coco/core.c:123:7: error: use of undeclared identifier 'sev_status' > > if (sev_status & MSR_AMD64_SNP_VTOM) > > ^ > > arch/x86/coco/core.c:139:7: error: use of undeclared identifier 'sev_status' > > if (sev_status & MSR_AMD64_SNP_VTOM) > > ^ > > 2 errors generated. > > make[3]: *** [scripts/Makefile.build:252: arch/x86/coco/core.o] Error 1 > > make[2]: *** [scripts/Makefile.build:494: arch/x86/coco] Error 2 > > make[1]: *** [scripts/Makefile.build:494: arch/x86] Error 2 > > make[1]: *** Waiting for unfinished jobs.... > > make: *** [Makefile:2025: .] Error 2 > > > > compiler is: > > > > Debian clang version 14.0.6-2 > > Target: x86_64-pc-linux-gnu > > Thread model: posix > > InstalledDir: /usr/bin > > > > .config is attached. > > > > OK, I see what went wrong. I had tested with CONFIG_AMD_MEM_ENCRYPT=n > and didn't see any compile problems. It turns out in my test, arch/x86/coco/core.c > wasn't built at all because I did not also have TDX configured, so I didn't see > any errors. But with CONFIG_INTEL_TDX_GUEST=y, coco/core.c gets built, and > the error with undefined sev_status pops out. > > The straightforward fix is somewhat ugly. That's to put #ifdef > CONFIG_AMD_MEM_ENCRYPT around the entire CC_VENDOR_AMD > case in cc_mkenc() and in cc_mkdec(). Or put it just around the test of > sev_status. > > Perhaps a cleaner way would be to have a "vendor_subtype" variable > declared in arch/x86/coco/core.c and tested instead of sev_status. > That subtype variable would be set from hv_vtom_init(), maybe via > a separate accessor function. But didn't I recently see a patch that > makes the existing "vendor" variable no longer static? In that case > just setting vendor_subtype without the accessor function may be > OK. > > What's your preference Boris? I can spin a v7 of the patch series > that fixes this, and that squashes the last two patches of the series > per Lorenz Pieralisi's comments. > Actually, a pretty clean approach is to #define sev_status 0ULL in the #else /* !CONFIG_AMD_MEM_ENCRYPT */ half of arch/x86/include/asm/mem_encrypt.h. That's where the existing extern statement is, and sme_me_mask is already handled that way. I'll respin the patch set with that approach. Michael
