On Fri, Nov 18, 2022 at 02:56:38PM +0000, Will Deacon wrote: > On Thu, Nov 10, 2022 at 01:53:26AM +0000, Oliver Upton wrote: > > As the SMCCC (and related specifications) march towards an > > 'everything and the kitchen sink' interface for interacting with a > > system, it is less likely that KVM will implement every supported > > feature. > > > > Add a capability that allows userspace to trap hypercall ranges, > > allowing the VMM to mix-and-match between calls handled in userspace vs. > > KVM. > > > > Signed-off-by: Oliver Upton <oliver.upton@xxxxxxxxx> > > --- > > arch/arm64/include/asm/kvm_host.h | 5 ++++ > > arch/arm64/include/uapi/asm/kvm.h | 15 ++++++++++ > > arch/arm64/kvm/arm.c | 10 +++++++ > > arch/arm64/kvm/hypercalls.c | 48 +++++++++++++++++++++++++++++++ > > include/uapi/linux/kvm.h | 1 + > > 5 files changed, 79 insertions(+) > > [...] > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > index 6f0b56e7f8c7..6e8a222fc295 100644 > > --- a/arch/arm64/kvm/arm.c > > +++ b/arch/arm64/kvm/arm.c > > @@ -100,6 +100,13 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > > r = 0; > > set_bit(KVM_ARCH_FLAG_SYSTEM_SUSPEND_ENABLED, &kvm->arch.flags); > > break; > > + case KVM_CAP_ARM_USER_HYPERCALLS: > > + if (cap->args[0] & ~KVM_ARM_USER_HYPERCALL_FLAGS) > > + return -EINVAL; > > Why not use KVM_CAP_EXIT_HYPERCALL for this? Err... I hilariously hijacked its UAPI for the exit but added a new cap for it :) I think the direction going forward will be to provide userspace with a range-based filter such that (to a degree) we can arbitrarily forward hypercalls to userspace, allowing for a mix-and-match approach. > At some point during pKVM > development, we used that to notify the VMM about memory being shared > back from the guest but we eventually dropped it as the notification to > userspace ended up not being needed: > > https://android-kvm.googlesource.com/linux/+/dbd2861832dfc4c8a3103214b3c212ee7ace1c44%5E%21/ > https://android-kvm.googlesource.com/linux/+/2a3afc6da99c0e0cb62be1687153ee572903aa80%5E%21/ > > I'm not saying that what we did was necessarily better, but it seems a bit > simpler and I figured it might be useful to point you to it. Yeah, this is certainly a lot cleaner than what I've proposed here. And frankly, for my immediate interest (forwarding vendor hypercalls to userspace), this would fit the bill. OTOH, I was hoping that something a bit more flexible could move the onus of implementing every darn spec onto userspace (where possible). I know you said pKVM has no need for userspace notifications at this moment, but could user hypercalls be useful again going forward? -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
