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?
Tycho
