| Message ID | 1569338454-26202-3-git-send-email-guoheyi@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add virtual SDEI support for arm64 | expand |
Hi Heyi, On 24/09/2019 16:20, Heyi Guo wrote: > Add new KVM capability "KVM_CAP_FORWARD_HYPERCALL" for user space to > probe whether KVM supports forwarding hypercall. > > The capability should be enabled by user space explicitly, for we > don't want user space application to deal with unexpected hypercall > exits. We also use an additional argument to pass exception bit mask, > to request KVM to forward all hypercalls except the classes specified > in the bit mask. > > Currently only PSCI can be set as exception, so that we can still keep > consistent with the old PSCI processing flow. I agree this needs to be default-on, but I don't think this exclusion mechanism is extensible. > diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c > index f4a8ae9..2201b62 100644 > --- a/arch/arm64/kvm/reset.c > +++ b/arch/arm64/kvm/reset.c > @@ -102,6 +105,28 @@ int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext) > return r; > } > > +int kvm_vm_ioctl_enable_cap(struct kvm *kvm, > + struct kvm_enable_cap *cap) > +{ > + if (cap->flags) > + return -EINVAL; > + > + switch (cap->cap) { > + case KVM_CAP_FORWARD_HYPERCALL: { > + __u64 exclude_flags = cap->args[0]; and if there are more than 64 things to exclude? > + /* Only support excluding PSCI right now */ > + if (exclude_flags & ~KVM_CAP_FORWARD_HYPERCALL_EXCL_PSCI) > + return -EINVAL; Once we have a 65th bit, older kernels will let user-space set it, but nothing happens. > + kvm->arch.hypercall_forward = true; > + if (exclude_flags & KVM_CAP_FORWARD_HYPERCALL_EXCL_PSCI) > + kvm->arch.hypercall_excl_psci = true; > + return 0; > + } > + } > + > + return -EINVAL; > +} While 4*64 'named bits' for SMC/HVC ranges might be enough, it is tricky to work with. Both the kernel and user-space have to maintain a list of bit->name and name->call-number-range, which may change over time. A case in point: According to PSCI's History (Section 7 of DEN022D), PSCIv1.1 added SYSTEM_RESET2, MEM_PROTECT and MEM_PROTECT_CHECK_RANGE. I think its simpler for the HYPERCALL thing to act as a catch-all, and we provide something to enumerate the list of function id's the kernel implements. We can then add controls to disable the PSCI (which I think is the only one we have a case for disabling). I think the PSCI disable should wait until it has a user. Thanks, James
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c index f4a8ae9..2201b62 100644 --- a/arch/arm64/kvm/reset.c +++ b/arch/arm64/kvm/reset.c @@ -95,6 +95,9 @@ int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext) r = has_vhe() && system_supports_address_auth() && system_supports_generic_auth(); break; + case KVM_CAP_FORWARD_HYPERCALL: + r = 1; + break; default: r = 0; } @@ -102,6 +105,28 @@ int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext) return r; } +int kvm_vm_ioctl_enable_cap(struct kvm *kvm, + struct kvm_enable_cap *cap) +{ + if (cap->flags) + return -EINVAL; + + switch (cap->cap) { + case KVM_CAP_FORWARD_HYPERCALL: { + __u64 exclude_flags = cap->args[0]; + /* Only support excluding PSCI right now */ + if (exclude_flags & ~KVM_CAP_FORWARD_HYPERCALL_EXCL_PSCI) + return -EINVAL; + kvm->arch.hypercall_forward = true; + if (exclude_flags & KVM_CAP_FORWARD_HYPERCALL_EXCL_PSCI) + kvm->arch.hypercall_excl_psci = true; + return 0; + } + } + + return -EINVAL; +} + unsigned int kvm_sve_max_vl; int kvm_arm_init_sve(void) diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 5e3f12d..e3e5787 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -711,6 +711,8 @@ struct kvm_enable_cap { __u8 pad[64]; }; +#define KVM_CAP_FORWARD_HYPERCALL_EXCL_PSCI (1 << 0) + /* for KVM_PPC_GET_PVINFO */ #define KVM_PPC_PVINFO_FLAGS_EV_IDLE (1<<0) @@ -996,6 +998,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_ARM_PTRAUTH_ADDRESS 171 #define KVM_CAP_ARM_PTRAUTH_GENERIC 172 #define KVM_CAP_PMU_EVENT_FILTER 173 +#define KVM_CAP_FORWARD_HYPERCALL 174 #ifdef KVM_CAP_IRQ_ROUTING
Add new KVM capability "KVM_CAP_FORWARD_HYPERCALL" for user space to probe whether KVM supports forwarding hypercall. The capability should be enabled by user space explicitly, for we don't want user space application to deal with unexpected hypercall exits. We also use an additional argument to pass exception bit mask, to request KVM to forward all hypercalls except the classes specified in the bit mask. Currently only PSCI can be set as exception, so that we can still keep consistent with the old PSCI processing flow. Signed-off-by: Heyi Guo <guoheyi@huawei.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Dave Martin <Dave.Martin@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: James Morse <james.morse@arm.com> Cc: Julien Thierry <julien.thierry.kdev@gmail.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> --- arch/arm64/kvm/reset.c | 25 +++++++++++++++++++++++++ include/uapi/linux/kvm.h | 3 +++ 2 files changed, 28 insertions(+)