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

[Marc Zyngier]

On Fri, 23 Aug 2024 16:41:55 +0100,
Will Deacon <will at kernel.org> wrote:
> 
> 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.

Honestly, whatever number of bits you have in mind, just double it and
run with it. We don't need to be precious about those, specially given
that bog-standard KVM is unlikely to grow any new PV hypercall (PTP
was enough of a disaster to cure me from that disease).

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.