On Thu, Feb 26, 2026, Tycho Andersen wrote:
> On Wed, Feb 25, 2026 at 09:44:15AM -0800, Sean Christopherson wrote:
> > Ya, I don't have a better idea. Bleeding VM types into the CCP driver
> > might be
> > a bit wonky, though I guess it is uAPI so it's certainly not a KVM-internal
> > detail.
>
> Turns out this approach breaks the selftests, which is at least one
> userspace:
>
> # ./sev_init2_tests
> Random seed: 0x6b8b4567
> ==== Test Assertion Failure ====
> x86/sev_init2_tests.c:141: have_sev_es ==
> !!(kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM))
> pid=12498 tid=12498 errno=0 - Success
> 1 0x0000000000402747: main at sev_init2_tests.c:141
> (discriminator 2)
> 2 0x00007f9adae2a1c9: ?? ??:0
> 3 0x00007f9adae2a28a: ?? ??:0
> 4 0x0000000000402934: _start at ??:?
> sev-es: KVM_CAP_VM_TYPES (15) does not match cpuid (checking 8)
>
> As near as I can tell qemu doesn't do the same anywhere. SNP guests
> run fine, and SEV-ES says something reasonable:
>
> qemu-system-x86_64: sev_launch_start: LAUNCH_START ret=1 fw_error=21 'Feature
> not supported'
> qemu-system-x86_64: sev_common_kvm_init: failed to create encryption context
> qemu-system-x86_64: failed to initialize kvm: Operation not permitted
>
> Thoughts?
Breaking selftests is totally fine, they don't count as real users (the whole
point is to validate KVM behavior; if we weren't allowed to break selftests, we
literally couldn't fix a huge pile of KVM bugs).
Even if a real VMM has a similar sanity check, I wouldn't consider an assertion
firing to be a breaking flaw. No matter what, the VMM won't be able to launch
an
SEV-ES guest.
For selftests, something like this?
have_sev_es = kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SEV_ES_VM);
TEST_ASSERT(!have_sev_es || kvm_cpu_has(X86_FEATURE_SEV_ES),
"sev-es: SEV_ES_VM supported without SEV_ES in CPUID");
have_snp = kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SNP_VM);
TEST_ASSERT(!have_snp || kvm_cpu_has(X86_FEATURE_SEV_SNP),
"sev-snp: SNP_VM supported with SEV_SNP in CPUID");
