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,
> + });
> + }
> +}
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.