Re: [PATCH v6 3/4] KVM: arm64: Report all the KVM/arm64-specific hypercalls

[Oliver Upton <oliver.upton@linux.dev>]

> > > This isn't right, vendor_hyp_bmap is very much load bearing. We have a
> > > documented UAPI that allows userspace to control the hypercalls exposed
> > > to the guest.
> > >
> > > The idea being a user wants kernel rollback safety and doesn't expose
> > > hypercalls that could potentially be revoked.
> > >
> > > https://docs.kernel.org/virt/kvm/arm/fw-pseudo-registers.html#bitmap-
> > feature-firmware-registers
> > 
> > To add:
> > 
> > KVM cannot advertise the DISCOVER_IMPL* stuff unconditionally, since the
> > expectation is that userspace implements these hypercalls. These bits
> > may need to be writable from userspace but have a reset value of 0.
> > 
> 
> Ok. So IIUC, vendor_hyp_bmap actually holds the information which Vendor Hyp
> services  are available to the user space and can be get/set using GET/SET _ONE_REG
> interfaces.

Right.

> Currently this bitmap is a 64 bit one and if we have to have a one to one mapping
> between these bitmap and the hypercall function numbers, then that requires
> some changes.
> 
> Because function numbers 2-63 are now reserved for pKVM and the new ones
> introduced in this series take 64 & 65.
> 
> May be we can have KVM_REG_ARM_VENDOR_HYP_BMAP_2  which represents
> 64-127?
> 
> Or can we take the next available bits(2 & 3) for KVM_REG_ARM_VENDOR_HYP_BMAP
> and then map it to the function number appropriately (64 & 65) when
> ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID is handled?
> 
> Thoughts?

Adding a second register seems reasonable so we can preserve the mapping
of bit position / hypercall #.

-- 
Thanks,
Oliver