Re: [PATCH v3] KVM: selftests: Add a test for KVM_CREATE_VM VM type enforcement

[Sean Christopherson <seanjc@google.com>]

A handful of nits, but no need for another version, I'll fixup when applying.

Thanks!

On Fri, Jul 10, 2026, Hemanth Selam wrote:
> diff --git a/tools/testing/selftests/kvm/vm_types_test.c b/tools/testing/selftests/kvm/vm_types_test.c
> new file mode 100644
> index 000000000000..e8ef3b018f6c
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/vm_types_test.c
> @@ -0,0 +1,50 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Verify that KVM_CREATE_VM accepts exactly the VM types enumerated by
> + * KVM_CAP_VM_TYPES, and rejects every other type with -EINVAL.
> + */
> +#include <errno.h>
> +#include <stdbool.h>
> +#include <unistd.h>
> +
> +#include <linux/kvm.h>
> +
> +#include "kvm_util.h"
> +#include "test_util.h"
> +
> +int main(void)
> +{
> +	unsigned int supported_types;
> +	unsigned long type;
> +	int kvm_fd, fd;

Probably worth declaring "fd" inside the for-loop.   Definitely a coin toss on
which is "better".

> +	TEST_REQUIRE(kvm_has_cap(KVM_CAP_VM_TYPES));
> +
> +	kvm_fd = open_kvm_dev_path_or_exit();
> +	supported_types = kvm_check_cap(KVM_CAP_VM_TYPES);
> +	pr_info("KVM_CAP_VM_TYPES: 0x%x\n", supported_types);

Rather than "KVM_CAP_VM_TYPES" print a more human friendly message, e.g.
"Supported VM Types: ", otherwise it's not entirely obvious that the message is
printing the result of KVM_CAP_VM_TYPES version the raw macro number.

> +
> +	/*
> +	 * KVM_CAP_VM_TYPES is a u32 bitmap, so only types 0..31 can ever be
> +	 * advertised.  Walk past that range as well to confirm that any
> +	 * out-of-range type is rejected rather than silently accepted.

Rather than lean on KVM internals, I think it makes sense to express this limitation
in terms of KVM_CHECK_EXTENSION's return values.  Which is still kinda sorta an
internal detail, but it's at least more visible to userspace.

Specifically, track supported_types as an "unsigned long", and then have the
comment talk about KVM's deliberately retristed return value, not how KVM tracks
its supported types internally.  As a bonus, the loop can iterate on the bits per
supported_types, not a hardcoded "64".

	/*
	 * For compatibility with 32-bit kernels, KVM_CHECK_EXTENSION restricts
	 * its return to 32-bit values, i.e. only types 0..31 can be advertised.
	 * Walk past that range as well to confirm that any out-of-range type is
	 * rejected rather than silently accepted (or truncated).
	 */
	for (type = 0; type < BITS_PER_TYPE(supported_types); type++) {

> +	 */
> +	for (type = 0; type < 64; type++) {
> +		bool supported = type < 32 && (supported_types & (1U << type));

And then if supported_types is an "unsigned long", the "type < 32" goes away.
A bonus to _that_ is that the test will Just Work if future KVM does enumerate
support for types > 31.

The bitwise-AND can also use BIT().

> +
> +		fd = __kvm_ioctl(kvm_fd, KVM_CREATE_VM, (void *)type);
> +
> +		if (supported) {
> +			TEST_ASSERT(fd >= 0,
> +				    "KVM_CREATE_VM(%lu) should succeed, KVM_CAP_VM_TYPES=0x%x",
> +				    type, supported_types);
> +			close(fd);

kvm_close()

> +		} else {
> +			TEST_ASSERT(fd < 0 && errno == EINVAL,
> +				    "KVM_CREATE_VM(%lu) should fail with EINVAL, KVM_CAP_VM_TYPES=0x%x",
> +				    type, supported_types);
> +		}
> +	}
> +
> +	return 0;
> +}
> diff --git a/tools/testing/selftests/kvm/x86/sev_init2_tests.c b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
> index 8db88c355f16..d4227dc922ab 100644
> --- a/tools/testing/selftests/kvm/x86/sev_init2_tests.c
> +++ b/tools/testing/selftests/kvm/x86/sev_init2_tests.c
> @@ -77,10 +77,6 @@ void test_vm_types(void)
>  {
>  	test_init2(KVM_X86_SEV_VM, &(struct kvm_sev_init){});
>  
> -	/*
> -	 * TODO: check that unsupported types cannot be created.  Probably
> -	 * a separate selftest.
> -	 */
>  	if (have_sev_es)
>  		test_init2(KVM_X86_SEV_ES_VM, &(struct kvm_sev_init){});
>  
> -- 
> 2.43.7
>