All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Pratik Rajesh Sampat <pratikrajesh.sampat@amd.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
	kvm@vger.kernel.org, shuah@kernel.org,  michael.roth@amd.com,
	pbonzini@redhat.com, pgonda@google.com,
	 linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 3/5] selftests: KVM: SEV IOCTL test
Date: Fri, 9 Aug 2024 08:45:11 -0700	[thread overview]
Message-ID: <ZrY5h746smS4j5ak@google.com> (raw)
In-Reply-To: <98c1f8e2-3b24-49c4-b5fc-506e4283248d@amd.com>

On Thu, Jul 11, 2024, Pratik Rajesh Sampat wrote:
> >> +static void sev_guest_status_assert(struct kvm_vm *vm, uint32_t type)
> >> +{
> >> +	struct kvm_sev_guest_status status;
> >> +	bool cond;
> >> +	int ret;
> >> +
> >> +	ret = __vm_sev_ioctl(vm, KVM_SEV_GUEST_STATUS, &status);
> >> +	cond = type == KVM_X86_SEV_VM ? !ret : ret;
> >> +	TEST_ASSERT(cond,
> >> +		    "KVM_SEV_GUEST_STATUS should fail, invalid VM Type.");
> >> +}
> >> +
> >> +static void test_sev_launch(void *guest_code, uint32_t type, uint64_t policy)
> >> +{
> >> +	struct kvm_vcpu *vcpu;
> >> +	struct kvm_vm *vm;
> >> +	struct ucall uc;
> >> +	bool cond;
> >> +	int ret;
> >> +
> > 
> > Maybe a block comment here indicating what you're actually doing would
> > be good, because I'm a bit confused.
> > 
> > A policy value of 0 is valid for SEV, so you expect each call to
> > succeed, right? And, actually, for SEV-ES the launch start will succeed,
> > too, but the launch update will fail because LAUNCH_UPDATE_VMSA is not
> > valid for SEV, but then the launch measure should succeed. Is that
> > right? What about the other calls?
> > 
> 
> Sure, I can do that.
> Yes for SEV, the policy value of 0 succeeds for everything except when
> we try to run and we see a KVM_EXIT_IO.
> 
> For SEV-ES, with the policy value of 0 - we don't see launch_start
> succeed. It fails with EIO in this case. Post that all the calls for
> SEV-ES also fail subsequent to that. I guess the core idea behind this
> test is to ensure that once the first bad case of launch_start fails, we
> should see a cascading list of failures.
>
> >> +	vm = vm_sev_create_with_one_vcpu(type, guest_code, &vcpu);
> >> +	ret = sev_vm_launch_start(vm, 0);
> >> +	cond = type == KVM_X86_SEV_VM ? !ret : ret;
> >> +	TEST_ASSERT(cond,

Don't bury the result in a local boolean.  It's confusing, and _worse_ for debug
as it makes it impossible to see what actually failed (the assert message will
simply print "cond", which is useless).


> >> +		    "KVM_SEV_LAUNCH_START should fail, invalid policy.");

This is a blatant lie, because the KVM_X86_SEV_VM case apparently expects success.
Similar to Tom's comments about explaing what this code is doing, these assert
messages need to explain what the actually expected result it, provide a hint as
to _why_ that result is expected, and print the result.  As is, this will be
unnecessarily difficult to debug if/when it fails.

  reply	other threads:[~2024-08-09 15:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10 22:05 [RFC 0/5] SEV Kernel Selftests Pratik R. Sampat
2024-07-10 22:05 ` [RFC 1/5] selftests: KVM: Add a basic SNP smoke test Pratik R. Sampat
2024-07-11 15:16   ` Peter Gonda
2024-07-11 16:21     ` Sampat, Pratik Rajesh
2024-07-11 15:56   ` Tom Lendacky
2024-07-11 16:23     ` Sampat, Pratik Rajesh
2024-07-10 22:05 ` [RFC 2/5] selftests: KVM: Decouple SEV ioctls from asserts Pratik R. Sampat
2024-07-11 15:19   ` Peter Gonda
2024-07-11 16:11   ` Peter Gonda
2024-07-11 16:27     ` Sampat, Pratik Rajesh
2024-08-09 15:40   ` Sean Christopherson
2024-08-13 15:23     ` Pratik R. Sampat
2024-08-13 15:27       ` Sean Christopherson
2024-08-13 15:30         ` Pratik R. Sampat
2024-07-10 22:05 ` [RFC 3/5] selftests: KVM: SEV IOCTL test Pratik R. Sampat
2024-07-11 15:23   ` Peter Gonda
2024-07-11 16:23     ` Sampat, Pratik Rajesh
2024-07-11 18:34   ` Tom Lendacky
2024-07-11 20:02     ` Sampat, Pratik Rajesh
2024-08-09 15:45       ` Sean Christopherson [this message]
2024-08-13 15:23         ` Pratik R. Sampat
2024-07-10 22:05 ` [RFC 4/5] selftests: KVM: SNP " Pratik R. Sampat
2024-07-11 15:57   ` Peter Gonda
2024-07-11 16:27     ` Sampat, Pratik Rajesh
2024-08-09 15:48   ` Sean Christopherson
2024-08-13 15:23     ` Pratik R. Sampat
2024-07-10 22:05 ` [RFC 5/5] selftests: KVM: SEV-SNP test for KVM_SEV_INIT2 Pratik R. Sampat
2024-07-11 15:57   ` Peter Gonda

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=ZrY5h746smS4j5ak@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=pgonda@google.com \
    --cc=pratikrajesh.sampat@amd.com \
    --cc=shuah@kernel.org \
    --cc=thomas.lendacky@amd.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.