Hey Oliver, 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? 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. Will _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
