public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: "Pratik R. Sampat" <pratikrajesh.sampat@amd.com>
Cc: kvm@vger.kernel.org, shuah@kernel.org, thomas.lendacky@amd.com,
	 michael.roth@amd.com, pbonzini@redhat.com, pgonda@google.com,
	 linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 2/5] selftests: KVM: Decouple SEV ioctls from asserts
Date: Tue, 13 Aug 2024 08:27:41 -0700	[thread overview]
Message-ID: <Zrt7bRGQJ1C9XZGy@google.com> (raw)
In-Reply-To: <5b32da03-addf-4f34-bcf4-76fbe420b8f5@amd.com>

On Tue, Aug 13, 2024, Pratik R. Sampat wrote:
> On 8/9/2024 10:40 AM, Sean Christopherson wrote:
> > On Wed, Jul 10, 2024, Pratik R. Sampat wrote:
> >> @@ -98,7 +100,7 @@ static inline void sev_register_encrypted_memory(struct kvm_vm *vm,
> >>  	vm_ioctl(vm, KVM_MEMORY_ENCRYPT_REG_REGION, &range);
> >>  }
> >>  
> >> -static inline void snp_launch_update_data(struct kvm_vm *vm, vm_paddr_t gpa,
> >> +static inline int snp_launch_update_data(struct kvm_vm *vm, vm_paddr_t gpa,
> >>  					   uint64_t size, uint8_t type)
> >>  {
> >>  	struct kvm_sev_snp_launch_update update_data = {
> >> @@ -108,10 +110,10 @@ static inline void snp_launch_update_data(struct kvm_vm *vm, vm_paddr_t gpa,
> >>  		.type = type,
> >>  	};
> >>  
> >> -	vm_sev_ioctl(vm, KVM_SEV_SNP_LAUNCH_UPDATE, &update_data);
> >> +	return __vm_sev_ioctl(vm, KVM_SEV_SNP_LAUNCH_UPDATE, &update_data);
> > 
> > Don't introduce APIs and then immediately rewrite all of the users.  If you want
> > to rework similar APIs, do the rework, then add the new APIs.  Doing things in
> > this order adds a pile of pointless churn.
> > 
> > But that's a moot point, because it's far easier to just add __snp_launch_update_data().
> > And if you look through other APIs in kvm_util.h, you'll see that the strong
> > preference is to let vm_ioctl(), or in this case vm_sev_ioctl(), do the heavy
> > lifting.  Yeah, it requires copy+pasting marshalling parameters into the struct,
> > but that's relatively uninteresting code, _and_ piggybacking the "good" version
> > means you can't do things like pass in a garbage virtual address (because the
> > "good" version always guarantees a good virtual address).
> 
> I am a little confused by this.
> 
> Are you suggesting that I leave the original functions intact with using
> vm_sev_ioctl() and have an additional variant such as
> __snp_launch_update_data() which calls into __vm_sev_ioctl() to decouple
> the ioctl from the assert for negative asserts?

Yes, this one.

> Or, do you suggest that I alter vm_sev_ioctl() to handle both positive
> and negative asserts?
> 
> Thanks!
> -Pratik
> 

  reply	other threads:[~2024-08-13 15:27 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 [this message]
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
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=Zrt7bRGQJ1C9XZGy@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox