kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	michael.roth@amd.com,  aik@amd.com
Subject: Re: [PATCH v2 11/11] selftests: kvm: add tests for KVM_SEV_INIT2
Date: Fri, 23 Feb 2024 09:18:04 -0800	[thread overview]
Message-ID: <ZdjTTK1TgN8B64zO@google.com> (raw)
In-Reply-To: <20240223104009.632194-12-pbonzini@redhat.com>

On Fri, Feb 23, 2024, Paolo Bonzini wrote:
> diff --git a/tools/testing/selftests/kvm/x86_64/sev_init2_tests.c b/tools/testing/selftests/kvm/x86_64/sev_init2_tests.c
> new file mode 100644
> index 000000000000..644fd5757041
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/x86_64/sev_init2_tests.c
> @@ -0,0 +1,146 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#include <linux/kvm.h>
> +#include <linux/psp-sev.h>
> +#include <stdio.h>
> +#include <sys/ioctl.h>
> +#include <stdlib.h>
> +#include <errno.h>
> +#include <pthread.h>
> +
> +#include "test_util.h"
> +#include "kvm_util.h"
> +#include "processor.h"
> +#include "svm_util.h"
> +#include "kselftest.h"
> +
> +#define SVM_SEV_FEAT_DEBUG_SWAP 32u
> +
> +/*
> + * Some features may have hidden dependencies, or may only work
> + * for certain VM types.  Err on the side of safety and don't
> + * expect that all supported features can be passed one by one
> + * to KVM_SEV_INIT2.
> + *
> + * (Well, right now there's only one...)
> + */
> +#define KNOWN_FEATURES SVM_SEV_FEAT_DEBUG_SWAP
> +
> +int kvm_fd;
> +u64 supported_vmsa_features;
> +bool have_sev_es;
> +
> +static int __sev_ioctl(int vm_fd, int cmd_id, void *data)
> +{
> +	struct kvm_sev_cmd cmd = {
> +		.id = cmd_id,
> +		.data = (uint64_t)data,
> +		.sev_fd = open_sev_dev_path_or_exit(),
> +	};
> +	int ret;
> +
> +	ret = ioctl(vm_fd, KVM_MEMORY_ENCRYPT_OP, &cmd);
> +	TEST_ASSERT(ret < 0 || cmd.error == SEV_RET_SUCCESS,
> +		    "%d failed: fw error: %d\n",
> +		    cmd_id, cmd.error);
> +
> +	return ret;

If you can hold off on v3 until next week, I'll get the SEV+SEV-ES smoke test
series into a branch and thus kvm-x86/next.  Then this can take advantage of the
library files and functions that are added there.  I don't know if it will save
much code, but it'll at least provide a better place to land some of the "library"
#define and helpers.


https://lore.kernel.org/all/20240223004258.3104051-1-seanjc@google.com

> +}
> +
> +static void test_init2(unsigned long vm_type, struct kvm_sev_init *init)
> +{
> +	struct kvm_vm *vm;
> +	int ret;
> +
> +	vm = vm_create_barebones_type(vm_type);
> +	ret = __sev_ioctl(vm->fd, KVM_SEV_INIT2, init);

The SEV library provided vm_sev_ioctl() for this.
> +	TEST_ASSERT(ret == 0,
> +		    "KVM_SEV_INIT2 return code is %d (expected 0), errno: %d",
> +		    ret, errno);

	TEST
> +	kvm_vm_free(vm);
> +}
> +
> +static void test_init2_invalid(unsigned long vm_type, struct kvm_sev_init *init)
> +{
> +	struct kvm_vm *vm;
> +	int ret;
> +
> +	vm = vm_create_barebones_type(vm_type);
> +	ret = __sev_ioctl(vm->fd, KVM_SEV_INIT2, init);

__vm_sev_ioctl() in the library.

> +	TEST_ASSERT(ret == -1 && errno == EINVAL,
> +		    "KVM_SEV_INIT2 return code %d, errno: %d (expected EINVAL)",
> +		    ret, errno);

TEST_ASSERT() will spit out the errno and it's user-friendly name.  I would prefer
the assert message to explain why failure was expected.  That way readers of the
code don't need a comment, and runners of failed tests get more info.

Hrm, though that'd require assing in a "const char *msg", which would limit this
to constant strings and no formatting.  I think that's still a net positive though.

	TEST_ASSERT(ret == -1 && errno == EINVAL,
		    "KVM_SET_INIT2 should fail, %s.", msg);

> +	kvm_vm_free(vm);
> +}
> +
> +void test_vm_types(void)
> +{
> +	test_init2(KVM_X86_SEV_VM, &(struct kvm_sev_init){});
> +
> +	if (have_sev_es)
> +		test_init2(KVM_X86_SEV_ES_VM, &(struct kvm_sev_init){});
> +	else
> +		test_init2_invalid(KVM_X86_SEV_ES_VM, &(struct kvm_sev_init){});

E.g. this could be something like

		test_init2_invalid(KVM_X86_SEV_ES_VM, &(struct kvm_sev_init){},
				   "SEV-ES unsupported);

Though shouldn't vm_create_barebones_type() fail on the unsupported VM type, not
KVM_SEV_INIT2?

> +
> +	test_init2_invalid(0, &(struct kvm_sev_init){});
> +	if (kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SW_PROTECTED_VM))
> +		test_init2_invalid(KVM_X86_SW_PROTECTED_VM, &(struct kvm_sev_init){});
> +}
> +
> +void test_flags(uint32_t vm_type)
> +{
> +	int i;
> +
> +	for (i = 0; i < 32; i++)
> +		test_init2_invalid(vm_type, &(struct kvm_sev_init){
> +			.flags = 1u << i,

BIT()

> +		});

And I think I'd prefer to have the line run long?  

		test_init2_invalid(vm_type, &(struct kvm_sev_init) { .flags = BIT(i) });
> +}
> +
> +void test_features(uint32_t vm_type, uint64_t supported_features)
> +{
> +	int i;
> +
> +	for (i = 0; i < 64; i++) {
> +		if (!(supported_features & (1u << i)))
> +			test_init2_invalid(vm_type, &(struct kvm_sev_init){
> +				.vmsa_features = 1u << i,
> +			});

Rather than create &(struct kvm_sev_init) for each path, this?

		struct kvm_sev_init init = {
			.vmsa_features = BIT(i);
		};

		if (!(supported_features & BIT(i))
			test_init2_invalid(vm_type, &init);
		else if (KNOWN_FEATURES & (1u << i))
			test_init2(vm_type, &init);

> +		else if (KNOWN_FEATURES & (1u << i))
> +			test_init2(vm_type, &(struct kvm_sev_init){
> +				.vmsa_features = 1u << i,
> +			});
> +	}
> +}

  reply	other threads:[~2024-02-23 17:18 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 10:39 [PATCH v2 00/11] KVM: SEV: allow customizing VMSA features Paolo Bonzini
2024-02-23 10:39 ` [PATCH v2 01/11] KVM: SEV: fix compat ABI for KVM_MEMORY_ENCRYPT_OP Paolo Bonzini
2024-02-23 14:20   ` Sean Christopherson
2024-02-23 15:04     ` Paolo Bonzini
2024-02-23 10:40 ` [PATCH v2 02/11] KVM: introduce new vendor op for KVM_GET_DEVICE_ATTR Paolo Bonzini
2024-02-23 14:45   ` Sean Christopherson
2024-02-23 15:03     ` Paolo Bonzini
2024-02-23 10:40 ` [PATCH v2 03/11] Documentation: kvm/sev: separate description of firmware Paolo Bonzini
2024-02-23 10:40 ` [PATCH v2 04/11] KVM: SEV: publish supported VMSA features Paolo Bonzini
2024-02-23 16:07   ` Sean Christopherson
2024-02-23 16:25     ` Paolo Bonzini
2024-02-23 16:41     ` Paolo Bonzini
2024-02-23 17:01       ` Sean Christopherson
2024-02-23 10:40 ` [PATCH v2 05/11] KVM: SEV: store VMSA features in kvm_sev_info Paolo Bonzini
2024-02-23 10:40 ` [PATCH v2 06/11] KVM: SEV: disable DEBUG_SWAP by default Paolo Bonzini
2024-02-23 16:08   ` Sean Christopherson
2024-02-23 10:40 ` [PATCH v2 07/11] KVM: x86: define standard behavior for bits 0/1 of VM type Paolo Bonzini
2024-02-23 16:46   ` Sean Christopherson
2024-02-23 16:48     ` Paolo Bonzini
2024-02-23 10:40 ` [PATCH v2 08/11] KVM: x86: Add is_vm_type_supported callback Paolo Bonzini
2024-02-23 16:51   ` Sean Christopherson
2024-02-23 10:40 ` [PATCH v2 09/11] KVM: SEV: define VM types for SEV and SEV-ES Paolo Bonzini
2024-02-23 16:55   ` Sean Christopherson
2024-02-23 17:22   ` Sean Christopherson
2024-02-23 10:40 ` [PATCH v2 10/11] KVM: SEV: introduce KVM_SEV_INIT2 operation Paolo Bonzini
2024-02-23 16:58   ` Sean Christopherson
2024-02-23 10:40 ` [PATCH v2 11/11] selftests: kvm: add tests for KVM_SEV_INIT2 Paolo Bonzini
2024-02-23 17:18   ` Sean Christopherson [this message]
2024-02-23 18:04     ` Paolo Bonzini
2024-02-23 14:52 ` [PATCH v2 00/11] KVM: SEV: allow customizing VMSA features Sean Christopherson
2024-02-23 15:04   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZdjTTK1TgN8B64zO@google.com \
    --to=seanjc@google.com \
    --cc=aik@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).