[0/3] KVM: selftests: Consolidate ucall code

Message

Sean Christopherson June 18, 2022, 12:16 a.m. UTC

Consolidate the code for making and getting ucalls.  All architectures pass
the ucall struct via memory, so filling and copying the struct is 100%
generic.  The only per-arch code is sending and receiving the address of
said struct.

Tested on x86 and arm, compile tested on s390 and RISC-V.

Sean Christopherson (3):
  KVM: selftests: Consolidate common code for popuplating ucall struct
  KVM: selftests: Consolidate boilerplate code in get_ucall()
  KVM: selftest: Add __weak stubs for ucall_arch_(un)init()

 tools/testing/selftests/kvm/Makefile          |  1 +
 .../selftests/kvm/include/ucall_common.h      | 17 ++++++-
 .../testing/selftests/kvm/lib/aarch64/ucall.c | 36 +++-----------
 tools/testing/selftests/kvm/lib/riscv/ucall.c | 44 ++---------------
 tools/testing/selftests/kvm/lib/s390x/ucall.c | 41 ++--------------
 .../testing/selftests/kvm/lib/ucall_common.c  | 49 +++++++++++++++++++
 .../testing/selftests/kvm/lib/x86_64/ucall.c  | 41 ++--------------
 7 files changed, 87 insertions(+), 142 deletions(-)
 create mode 100644 tools/testing/selftests/kvm/lib/ucall_common.c


base-commit: 8baacf67c76c560fed954ac972b63e6e59a6fba0

Comments

Andrew Jones June 20, 2022, 7:33 a.m. UTC | #1

On Sat, Jun 18, 2022 at 12:16:15AM +0000, Sean Christopherson wrote:
> Consolidate the code for making and getting ucalls.  All architectures pass
> the ucall struct via memory, so filling and copying the struct is 100%
> generic.  The only per-arch code is sending and receiving the address of
> said struct.
> 
> Tested on x86 and arm, compile tested on s390 and RISC-V.

For the series

Reviewed-by: Andrew Jones <[e-mail]>

Thanks,
drew

Paolo Bonzini June 20, 2022, 12:03 p.m. UTC | #2

On 6/18/22 02:16, Sean Christopherson wrote:
> Consolidate the code for making and getting ucalls.  All architectures pass
> the ucall struct via memory, so filling and copying the struct is 100%
> generic.  The only per-arch code is sending and receiving the address of
> said struct.
> 
> Tested on x86 and arm, compile tested on s390 and RISC-V.

I'm not sure about doing this yet.  The SEV tests added multiple 
implementations of the ucalls in one architecture.  I have rebased those 
recently (not the SEV part) to get more familiar with the new kvm_vcpu 
API for selftests, and was going to look at your old review next...

Paolo

Sean Christopherson June 21, 2022, 2:54 p.m. UTC | #3

On Mon, Jun 20, 2022, Paolo Bonzini wrote:
> On 6/18/22 02:16, Sean Christopherson wrote:
> > Consolidate the code for making and getting ucalls.  All architectures pass
> > the ucall struct via memory, so filling and copying the struct is 100%
> > generic.  The only per-arch code is sending and receiving the address of
> > said struct.
> > 
> > Tested on x86 and arm, compile tested on s390 and RISC-V.
> 
> I'm not sure about doing this yet.  The SEV tests added multiple
> implementations of the ucalls in one architecture.  I have rebased those
> recently (not the SEV part) to get more familiar with the new kvm_vcpu API
> for selftests, and was going to look at your old review next...

I had forgotten about that code.  My idea of a per-VM list[*] would fit nicely on
top, though maybe drop the last patch from this series.

[*] https://lore.kernel.org/all/[e-mail]

Peter Gonda July 15, 2022, 7:32 p.m. UTC | #4

On Tue, Jun 21, 2022 at 8:55 AM Sean Christopherson <[e-mail]> wrote:
>
> On Mon, Jun 20, 2022, Paolo Bonzini wrote:
> > On 6/18/22 02:16, Sean Christopherson wrote:
> > > Consolidate the code for making and getting ucalls.  All architectures pass
> > > the ucall struct via memory, so filling and copying the struct is 100%
> > > generic.  The only per-arch code is sending and receiving the address of
> > > said struct.
> > >
> > > Tested on x86 and arm, compile tested on s390 and RISC-V.
> >
> > I'm not sure about doing this yet.  The SEV tests added multiple
> > implementations of the ucalls in one architecture.  I have rebased those
> > recently (not the SEV part) to get more familiar with the new kvm_vcpu API
> > for selftests, and was going to look at your old review next...
>
> I had forgotten about that code.  My idea of a per-VM list[*] would fit nicely on
> top, though maybe drop the last patch from this series.
>
> [*] https://lore.kernel.org/all/[e-mail]

I just sent an RFC of SEV selftesting using Sean's suggestion built on
the first 2 patches in this series. I think they work well with the
encrypted VMs ucalling.

https://lore.kernel.org/all/[e-mail]/