On 9/12/25 14:41, Sean Christopherson wrote: > On Fri, Sep 12, 2025, Tom Lendacky wrote: >> On 9/12/25 13:34, Sean Christopherson wrote: >>> But the below build failures show that they aren't dead code, which means that >>> kernels with CONFIG_KVM_AMD_SEV=n will silently (until something explodes) do the >>> wrong thing, because the stubs are hiding the missing dependencies. >>> >>> arch/x86/boot/startup/sev-shared.c: In function ‘pvalidate_4k_page’: >>> arch/x86/boot/startup/sev-shared.c:820:17: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration] >>> 820 | sev_evict_cache((void *)vaddr, 1); >> >> Yeah, this one is on me. sev_evict_cache() is guest code and should be >> under the CONFIG_AMD_MEM_ENCRYPT #ifdef. >> >>> | ^~~~~~~~~~~~~~~ >>> AR arch/x86/realmode/built-in.a >>> arch/x86/coco/sev/core.c: In function ‘pvalidate_pages’: >>> arch/x86/coco/sev/core.c:386:25: error: implicit declaration of function ‘sev_evict_cache’ [-Wimplicit-function-declaration] >>> 386 | sev_evict_cache(pfn_to_kaddr(e->gfn), e->pagesize ? 512 : 1); >>> | ^~~~~~~~~~~~~~~ >>> arch/x86/mm/mem_encrypt.c: In function ‘mem_encrypt_setup_arch’: >>> arch/x86/mm/mem_encrypt.c:112:17: error: implicit declaration of function ‘snp_fixup_e820_tables’ [-Wimplicit-function-declaration] >>> 112 | snp_fixup_e820_tables(); >> >> This function is only meant to be used if we're going to run SEV guests, >> so being guarded by CONFIG_KVM_AMD_SEV was on purpose. I'm just not sure >> why the stub didn't get used... or did you remove them? > > I removed all the stubs to see what would break (I was expecting nothing since > all of KVM's accesses are gated by CONFIG_KVM_AMD_SEV). Ah, ok. During the SNP host/hypervisor enablement there was feedback about doing all the RMP type stuff based on whether the kernel could run SNP guests. So that's why we see things outside of the KVM tree using CONFIG_KVM_AMD_SEV. Thanks, Tom
