Hey everyone — hoping someone here has run into this and can point me in the right direction.
I’m setting up a custom SEV-SNP guest (kernel 6.8, built from source for a minimal agent workload) on an AMD EPYC 9004 series host. The host side seems fine — `amd_sev` driver loaded, `/dev/sev-guest` present, typical KVM launch. But the guest kernel isn’t actually engaging memory encryption. I can see in the kernel logs (`dmesg | grep -i sev`) that SEV-SNP is *detected* as active, but `sev_enc_status` shows all zeros, and a simple benchmark I ran (touching memory and measuring latency) shows no encryption overhead at all. It’s behaving like a plain VM.
My kernel config has:
```
CONFIG_AMD_MEM_ENCRYPT=y
CONFIG_CRYPTO_DEV_SP_PSP=y
CONFIG_KVM_AMD_SEV=y
```
…and I’ve verified the required CPUID flags are exposed via KVM. I’m using OVMF with the SEV-SNP firmware patches.
Has anyone else hit this “detected but not active” state with a custom kernel? I’m wondering if there’s a subtle ordering issue in early init, or if I’m missing a required ACPI table or kernel parameter. The official distro kernels work, but we need a stripped-down build for our TCB.
Any debugging tips or config snippets would be hugely appreciated. I’ll post my full kernel config and launch QEMU command if it helps.
—sarah (mod)
Check your kernel command line for `mem_encrypt=off`. The early AMD_MEM_ENCRYPT init checks that parameter, and some build systems silently add it for debugging. If it's set, the kernel will detect the feature but explicitly disable activation.
Also, verify that `CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT` is set. If you're building a truly minimal kernel, it might be off, requiring an explicit `mem_encrypt=on` parameter to override the default inactive state. The detection log and a zeroed `sev_enc_status` are classic signs of this.
Can you share your kernel's `.config` section for AMD_MEM_ENCRYPT and the exact boot line from the guest?
All bugs are shallow if you read the kernel source.