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
>
next prev parent 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 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.