KVM: selftests: Add a test for KVM_CREATE_VM VM type enforcement

KVM_CAP_VM_TYPES advertises the bitmap of VM types that KVM_CREATE_VM
accepts, but nothing verified that the ioctl actually enforces it: that
every advertised type can be created and every non-advertised type is
rejected. sev_init2_tests carried a TODO for this ("check that
unsupported types cannot be created. Probably a separate selftest"),
but the check is not specific to SEV or KVM_SEV_INIT2, and not even to
x86.

Add a standalone test that walks the type space and, for each value,
asserts that KVM_CREATE_VM succeeds iff the corresponding bit is set in
KVM_CAP_VM_TYPES, and otherwise fails with -EINVAL. The walk extends
past bit 31 so that out-of-range type values, which can never be
advertised in the u32 bitmap, are also confirmed to be rejected. The
test only depends on KVM_CAP_VM_TYPES, so it lives in the common set and
is skipped on architectures that don't advertise the capability.

Drop the now-addressed TODO from sev_init2_tests.c.

Tested on an AMD SEV-SNP capable host. With KVM_CAP_VM_TYPES=0x15
(DEFAULT/SEV/SNP), only the advertised types are created and everything
else is rejected:

  $ strace -e trace=ioctl ./vm_types_test 2>&1 | grep KVM_CREATE_VM
  ioctl(3, KVM_CREATE_VM, 0)    = 4              # DEFAULT
  ioctl(3, KVM_CREATE_VM, 0x1)  = -1 EINVAL      # SW_PROTECTED
  ioctl(3, KVM_CREATE_VM, 0x2)  = 4              # SEV
  ioctl(3, KVM_CREATE_VM, 0x3)  = -1 EINVAL      # SEV-ES
  ioctl(3, KVM_CREATE_VM, 0x4)  = 4              # SNP
  ioctl(3, KVM_CREATE_VM, 0x5)  = -1 EINVAL      # TDX
  ... 0x6..0x3f all -1 EINVAL ...

Reloading kvm_amd with sev_snp=0 drops the bitmap to 0x5 and only types
0 and 2 are then created, confirming the test tracks the advertised set
rather than hard-coded types.

Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260710050442.826777-1-hemanth.selam@gmail.com
Signed-off-by: Sean Christopherson <seanjc@google.com>

0 files changed, 0 insertions, 0 deletions