[PATCH 4/6] drivers/virt: pkvm: Hook up mem_encrypt API using pKVM hypercalls

[Will Deacon]

Hi Marc,

On Wed, Aug 21, 2024 at 05:49:45PM +0100, Marc Zyngier wrote:
> On Tue, 30 Jul 2024 16:11:10 +0100,
> Will Deacon <will at kernel.org> wrote:
> > 
> > If we detect the presence of pKVM's SHARE and UNSHARE hypercalls, then
> > register a backend implementation of the mem_encrypt API so that things
> > like DMA buffers can be shared appropriately with the host.
> > 
> > Signed-off-by: Will Deacon <will at kernel.org>
> > ---
> >  Documentation/virt/kvm/arm/hypercalls.rst     | 50 +++++++++++++++++
> >  drivers/virt/coco/pkvm-guest/arm-pkvm-guest.c | 55 +++++++++++++++++++
> >  include/linux/arm-smccc.h                     | 14 +++++
> >  3 files changed, 119 insertions(+)
> > 
> 
> [...]
> 
> > diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> > index 16b6dcc54e02..9cb7c95920b0 100644
> > --- a/include/linux/arm-smccc.h
> > +++ b/include/linux/arm-smccc.h
> > @@ -116,6 +116,8 @@
> >  #define ARM_SMCCC_KVM_FUNC_FEATURES		0
> >  #define ARM_SMCCC_KVM_FUNC_PTP			1
> >  #define ARM_SMCCC_KVM_FUNC_HYP_MEMINFO		2
> > +#define ARM_SMCCC_KVM_FUNC_MEM_SHARE		3
> > +#define ARM_SMCCC_KVM_FUNC_MEM_UNSHARE		4
> >  #define ARM_SMCCC_KVM_FUNC_FEATURES_2		127
> >  #define ARM_SMCCC_KVM_NUM_FUNCS			128
> 
> As you will certainly add a bunch of other calls (hopefully soon-ish),
> how about reserving an actual range for those, so that we can
> future-proof the ABI early?
> 
> Grab 64 right away, and we don't have to worry about new stuff for a
> while.
> 
> What do you think?

I think that's incredibly generous. Let's see whether we really need
that to start with...

/me dives into android15-6.6

So we currently allocate 3-11 there and some of those are because we
messed up v1 of a hypercall and had to introduce a new one. I don't plan
to inflict that on upstream, but avoiding conflicts would be good.

The big thing on the horizon is a hypercall-based IOMMU interface which
looks like it will need ~10 new calls. I suppose we could multiplex some
of that, but otherwise 32 would probably do us if you don't want to give
up such a big chunk of the space immediately.

Will