public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Peter Gonda <pgonda@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	marcorr@google.com, michael.roth@amd.com,
	thomas.lendacky@amd.com, joro@8bytes.org, mizhang@google.com,
	pbonzini@redhat.com, andrew.jones@linux.dev,
	vannapurve@google.com
Subject: Re: [V3 11/11] KVM: selftests: Add simple sev vm testing
Date: Thu, 18 Aug 2022 00:22:15 +0000	[thread overview]
Message-ID: <Yv2GN1WPvi7K8LdI@google.com> (raw)
In-Reply-To: <20220810152033.946942-12-pgonda@google.com>

/sev_vm_launch_measurOn Wed, Aug 10, 2022, Peter Gonda wrote:
> diff --git a/tools/testing/selftests/kvm/include/x86_64/sev.h b/tools/testing/selftests/kvm/include/x86_64/sev.h
> index 2f7f7c741b12..b6552ea1c716 100644
> --- a/tools/testing/selftests/kvm/include/x86_64/sev.h
> +++ b/tools/testing/selftests/kvm/include/x86_64/sev.h
> @@ -22,6 +22,9 @@
>  #define SEV_POLICY_NO_DBG	(1UL << 0)
>  #define SEV_POLICY_ES		(1UL << 2)
>  
> +#define CPUID_MEM_ENC_LEAF 0x8000001f
> +#define CPUID_EBX_CBIT_MASK 0x3f

Ha!  I was going to say "put these in processor.h", but I have an even better idea.
I'll try to a series posted tomorrow (compile tested only at this point), but what
I'm hoping to do is to allow automagic retrieval of multi-bit CPUID properties, a la
the existing this_cpu_has() stuff.

E.g.

	#define X86_PROPERTY_CBIT_LOCATION		KVM_X86_CPU_PROPERTY(0x8000001F, 0, EBX, 0, 5)

and then

	sev->enc_bit = this_cpu_property(X86_PROPERTY_CBIT_LOCATION);

LOL, now I see that the defines in sev.c were introduced back in patch 08.  That's
probably fine for your submission so as not to take a dependency on the "property"
idea.  This patch doesn't need to move the CPUID_* defines because it can use
this_cpu_has(X86_FEATURE_SEV) and avoid referencing CPUID_MEM_ENC_LEAF.

>  enum {
>  	SEV_GSTATE_UNINIT = 0,
>  	SEV_GSTATE_LUPDATE,
> diff --git a/tools/testing/selftests/kvm/lib/x86_64/sev.c b/tools/testing/selftests/kvm/lib/x86_64/sev.c
> index 3abcf50c0b5d..8f9f55c685a7 100644
> --- a/tools/testing/selftests/kvm/lib/x86_64/sev.c
> +++ b/tools/testing/selftests/kvm/lib/x86_64/sev.c
> @@ -13,8 +13,6 @@
>  #include "sev.h"
>  
>  #define PAGE_SHIFT		12

Already defined in processor.h

> -#define CPUID_MEM_ENC_LEAF 0x8000001f
> -#define CPUID_EBX_CBIT_MASK 0x3f
>  
>  struct sev_vm {
>  	struct kvm_vm *vm;
> diff --git a/tools/testing/selftests/kvm/x86_64/sev_all_boot_test.c b/tools/testing/selftests/kvm/x86_64/sev_all_boot_test.c
> new file mode 100644
> index 000000000000..b319d18bdb60
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/x86_64/sev_all_boot_test.c
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Basic SEV boot tests.
> + *
> + * Copyright (C) 2021 Advanced Micro Devices
> + */
> +#define _GNU_SOURCE /* for program_invocation_short_name */
> +#include <fcntl.h>
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <sys/ioctl.h>
> +
> +#include "test_util.h"
> +
> +#include "kvm_util.h"
> +#include "processor.h"
> +#include "svm_util.h"
> +#include "linux/psp-sev.h"
> +#include "sev.h"
> +
> +#define VCPU_ID			2

Nooooooo.  Unless there is a really, REALLY good reason this needs to be '2', just
pass '0' as a literal to vm_vcpu_add() and delete VCPU_ID.

> +#define PAGE_STRIDE		32
> +
> +#define SHARED_PAGES		8192
> +#define SHARED_VADDR_MIN	0x1000000
> +
> +#define PRIVATE_PAGES		2048
> +#define PRIVATE_VADDR_MIN	(SHARED_VADDR_MIN + SHARED_PAGES * PAGE_SIZE)
> +
> +#define TOTAL_PAGES		(512 + SHARED_PAGES + PRIVATE_PAGES)
> +
> +#define NR_SYNCS 1
> +
> +static void guest_run_loop(struct kvm_vcpu *vcpu)
> +{
> +	struct ucall uc;
> +	int i;
> +
> +	for (i = 0; i <= NR_SYNCS; ++i) {
> +		vcpu_run(vcpu);
> +		switch (get_ucall(vcpu, &uc)) {
> +		case UCALL_SYNC:
> +			continue;
> +		case UCALL_DONE:
> +			return;
> +		case UCALL_ABORT:
> +			TEST_ASSERT(false, "%s at %s:%ld\n\tvalues: %#lx, %#lx",
> +				    (const char *)uc.args[0], __FILE__,
> +				    uc.args[1], uc.args[2], uc.args[3]);
> +		default:
> +			TEST_ASSERT(
> +				false, "Unexpected exit: %s",
> +				exit_reason_str(vcpu->run->exit_reason));
> +		}
> +	}
> +}
> +
> +static void __attribute__((__flatten__)) guest_sev_code(void)

Is __flatten__ strictly necessary?  I don't see this being copied over anything
that would require it to be a contiguous chunk.

> +{
> +	uint32_t eax, ebx, ecx, edx;
> +	uint64_t sev_status;
> +
> +	GUEST_SYNC(1);
> +
> +	cpuid(CPUID_MEM_ENC_LEAF, &eax, &ebx, &ecx, &edx);
> +	GUEST_ASSERT(eax & (1 << 1));

	GUEST_ASSERT(this_cpu_has(X86_FEATURE_SEV));
> +
> +	sev_status = rdmsr(MSR_AMD64_SEV);
> +	GUEST_ASSERT((sev_status & 0x1) == 1);
> +
> +	GUEST_DONE();
> +}
> +
> +static struct sev_vm *setup_test_common(void *guest_code, uint64_t policy,
> +					struct kvm_vcpu **vcpu)
> +{
> +	uint8_t measurement[512];
> +	struct sev_vm *sev;
> +	struct kvm_vm *vm;
> +	int i;
> +
> +	sev = sev_vm_create(policy, TOTAL_PAGES);

	TEST_ASSERT(sev, ...) so that this doesn't silently "pass"?

> +	if (!sev)
> +		return NULL;
> +	vm = sev_get_vm(sev);
> +
> +	/* Set up VCPU and initial guest kernel. */
> +	*vcpu = vm_vcpu_add(vm, VCPU_ID, guest_code);
> +	kvm_vm_elf_load(vm, program_invocation_name);
> +
> +	/* Allocations/setup done. Encrypt initial guest payload. */
> +	sev_vm_launch(sev);
> +
> +	/* Dump the initial measurement. A test to actually verify it would be nice. */
> +	sev_vm_launch_measure(sev, measurement);
> +	pr_info("guest measurement: ");
> +	for (i = 0; i < 32; ++i)
> +		pr_info("%02x", measurement[i]);
> +	pr_info("\n");
> +
> +	sev_vm_launch_finish(sev);
> +
> +	return sev;
> +}
> +
> +static void test_sev(void *guest_code, uint64_t policy)
> +{
> +	struct sev_vm *sev;
> +	struct kvm_vcpu *vcpu;
> +
> +	sev = setup_test_common(guest_code, policy, &vcpu);
> +	if (!sev)
> +		return;

And with an assert above, this return goes away.  Or better yet, fold setup_test_common()
into test_sev(), there's only the one user of the so called "common" function.

> +
> +	/* Guest is ready to run. Do the tests. */
> +	guest_run_loop(vcpu);
> +
> +	pr_info("guest ran successfully\n");
> +
> +	sev_vm_free(sev);
> +}
> +
> +int main(int argc, char *argv[])
> +{
> +	/* SEV tests */
> +	test_sev(guest_sev_code, SEV_POLICY_NO_DBG);
> +	test_sev(guest_sev_code, 0);
> +
> +	return 0;
> +}
> -- 
> 2.37.1.559.g78731f0fdb-goog
> 

  reply	other threads:[~2022-08-18  0:22 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-10 15:20 [V3 00/11] KVM: selftests: Add simple SEV test Peter Gonda
2022-08-10 15:20 ` [V3 01/11] KVM: selftests: move vm_phy_pages_alloc() earlier in file Peter Gonda
2022-08-10 15:20 ` [V3 02/11] KVM: selftests: sparsebit: add const where appropriate Peter Gonda
2022-08-10 15:20 ` [V3 03/11] KVM: selftests: add hooks for managing encrypted guest memory Peter Gonda
2022-08-10 15:20 ` [V3 04/11] KVM: selftests: handle encryption bits in page tables Peter Gonda
2022-08-10 15:20 ` [V3 05/11] KVM: selftests: add support for encrypted vm_vaddr_* allocations Peter Gonda
2022-08-10 15:20 ` [V3 06/11] KVM: selftests: Consolidate common code for popuplating Peter Gonda
2022-08-16 15:26   ` Andrew Jones
2022-08-10 15:20 ` [V3 07/11] KVM: selftests: Consolidate boilerplate code in get_ucall() Peter Gonda
2022-08-16 15:32   ` Andrew Jones
2022-08-10 15:20 ` [V3 08/11] KVM: selftests: add library for creating/interacting with SEV guests Peter Gonda
2022-08-18  0:33   ` Sean Christopherson
2022-08-29 15:45     ` Peter Gonda
2022-08-10 15:20 ` [V3 09/11] tools: Add atomic_test_and_set_bit() Peter Gonda
2022-08-16 14:26   ` Sean Christopherson
2022-08-10 15:20 ` [V3 10/11] KVM: selftests: Add ucall pool based implementation Peter Gonda
2022-08-16 16:13   ` Andrew Jones
2022-08-18 16:00     ` Sean Christopherson
2022-08-18 19:05       ` Andrew Jones
2022-08-18 23:29         ` Sean Christopherson
2022-08-19  5:17           ` Andrew Jones
2022-08-19 18:02             ` Sean Christopherson
2022-08-19 20:51               ` Sean Christopherson
2022-08-19 19:27   ` Vishal Annapurve
2022-08-19 19:37     ` Sean Christopherson
2022-08-22 23:55       ` Vishal Annapurve
2022-08-10 15:20 ` [V3 11/11] KVM: selftests: Add simple sev vm testing Peter Gonda
2022-08-18  0:22   ` Sean Christopherson [this message]
2022-08-29 15:38     ` Peter Gonda
2022-08-18 18:43   ` Sean Christopherson

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=Yv2GN1WPvi7K8LdI@google.com \
    --to=seanjc@google.com \
    --cc=andrew.jones@linux.dev \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcorr@google.com \
    --cc=michael.roth@amd.com \
    --cc=mizhang@google.com \
    --cc=pbonzini@redhat.com \
    --cc=pgonda@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vannapurve@google.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