public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Andrew Jones <andrew.jones@linux.dev>
Cc: Peter Gonda <pgonda@google.com>,
	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, vannapurve@google.com
Subject: Re: [V3 10/11] KVM: selftests: Add ucall pool based implementation
Date: Thu, 18 Aug 2022 16:00:40 +0000	[thread overview]
Message-ID: <Yv5iKJbjW5VseagS@google.com> (raw)
In-Reply-To: <20220816161350.b7x5brnyz5pyi7te@kamzik>

On Tue, Aug 16, 2022, Andrew Jones wrote:
> On Wed, Aug 10, 2022 at 08:20:32AM -0700, Peter Gonda wrote:
> > diff --git a/tools/testing/selftests/kvm/lib/aarch64/ucall.c b/tools/testing/selftests/kvm/lib/aarch64/ucall.c
> > index 132c0e98bf49..ee70531e8e51 100644
> > --- a/tools/testing/selftests/kvm/lib/aarch64/ucall.c
> > +++ b/tools/testing/selftests/kvm/lib/aarch64/ucall.c
> > @@ -81,12 +81,16 @@ void *ucall_arch_get_ucall(struct kvm_vcpu *vcpu)
> >  
> >  	if (run->exit_reason == KVM_EXIT_MMIO &&
> >  	    run->mmio.phys_addr == (uint64_t)ucall_exit_mmio_addr) {
> > -		vm_vaddr_t gva;
> > +		uint64_t ucall_addr;
> 
> Why change this vm_vaddr_t to a uint64_t? We shouldn't, because...
> 
> >  
> >  		TEST_ASSERT(run->mmio.is_write && run->mmio.len == 8,
> >  			    "Unexpected ucall exit mmio address access");
> > -		memcpy(&gva, run->mmio.data, sizeof(gva));
> > -		return addr_gva2hva(vcpu->vm, gva);
> > +		memcpy(&ucall_addr, run->mmio.data, sizeof(ucall_addr));
> 
> ...here we assume it's a vm_vaddr_t and only...
> 
> > +
> > +		if (vcpu->vm->use_ucall_pool)
> > +			return (void *)ucall_addr;
> 
> ...here do we know otherwise. So only here should be any casting.

It technically should be a union, because if sizeof(vm_vaddr_t) < sizeof(void *)
then declaring it as a vm_addr_t will do the wrong thing.  But then it's possible
that this could read too many bytes and inducs failure.  So I guess what we really
need is a "static_assert(sizeof(vm_vaddr_t) == sizeof(void *))".

But why is "use_ucall_pool" optional?  Unless there's a use case that fundamentally
conflicts with the pool approach, let's make the pool approach the _only_ approach.
IIRC, ARM's implementation isn't thread safe, i.e. there's at least one other use
case that _needs_ the pool implementation.

By supporting both, we are signing ourselves up for extra maintenance and pain,
e.g. inevitably we'll break whichever option isn't the default and not notice for
quite some time.

  reply	other threads:[~2022-08-18 16:00 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 [this message]
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
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=Yv5iKJbjW5VseagS@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