On Thu, Oct 31, 2024, Binbin Wu wrote: > On 10/31/2024 4:49 AM, Sean Christopherson wrote: > > On Mon, Aug 26, 2024, Binbin Wu wrote: > > > Check whether a KVM hypercall needs to exit to userspace or not based on > > > hypercall_exit_enabled field of struct kvm_arch. > > > > > > Userspace can request a hypercall to exit to userspace for handling by > > > enable KVM_CAP_EXIT_HYPERCALL and the enabled hypercall will be set in > > > hypercall_exit_enabled. Make the check code generic based on it. > > > > > > Signed-off-by: Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx> > > > Reviewed-by: Kai Huang <kai.huang@xxxxxxxxx> > > > --- > > > arch/x86/kvm/x86.c | 5 +++-- > > > arch/x86/kvm/x86.h | 4 ++++ > > > 2 files changed, 7 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > > index 966fb301d44b..e521f14ad2b2 100644 > > > --- a/arch/x86/kvm/x86.c > > > +++ b/arch/x86/kvm/x86.c > > > @@ -10220,8 +10220,9 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) > > > cpl = kvm_x86_call(get_cpl)(vcpu); > > > ret = __kvm_emulate_hypercall(vcpu, nr, a0, a1, a2, a3, op_64_bit, cpl); > > > - if (nr == KVM_HC_MAP_GPA_RANGE && !ret) > > > - /* MAP_GPA tosses the request to the user space. */ > > > + /* Check !ret first to make sure nr is a valid KVM hypercall. */ > > > + if (!ret && user_exit_on_hypercall(vcpu->kvm, nr)) > > I don't love that the caller has to re-check for user_exit_on_hypercall(). > Agree, it is not ideal. > > But if __kvm_emulate_hypercall() returns 0 to indicate user exit and 1 to > indicate success, then the callers have to convert the return code to set > return value for guest. E.g., TDX code also needs to do the conversion. Yeah, it's ugly. > > @@ -10111,12 +10111,21 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu) > > cpl = kvm_x86_call(get_cpl)(vcpu); > > ret = __kvm_emulate_hypercall(vcpu, nr, a0, a1, a2, a3, op_64_bit, cpl); > > - if (nr == KVM_HC_MAP_GPA_RANGE && !ret) > > - /* MAP_GPA tosses the request to the user space. */ > > + if (!ret) > > return 0; > > - if (!op_64_bit) > > + /* > > + * KVM's ABI with the guest is that '0' is success, and any other value > > + * is an error code. Internally, '0' == exit to userspace (see above) > > + * and '1' == success, as KVM's de facto standard return codes are that > > + * plus -errno == failure. Explicitly check for '1' as some PV error > > + * codes are positive values. > > + */ > I didn't understand the last sentence: > "Explicitly check for '1' as some PV error codes are positive values." > > The functions called in __kvm_emulate_hypercall() for PV features return > -KVM_EXXX for error code. > Did you mean the functions like kvm_pv_enable_async_pf(), which return > 1 for error, would be called in __kvm_emulate_hypercall() in the future? > If this is the concern, then we cannot simply convert 1 to 0 then. No, it was a brain fart on my end. I was thinking of these #defines, and managed to forget that KVM always returns -KVM_Exxx. /facepalm #define KVM_ENOSYS 1000 #define KVM_EFAULT EFAULT #define KVM_EINVAL EINVAL #define KVM_E2BIG E2BIG #define KVM_EPERM EPERM #define KVM_EOPNOTSUPP 95 > > > + if (ret == 1) > > + ret = 0; > > + else if (!op_64_bit) > > ret = (u32)ret; > > + > > kvm_rax_write(vcpu, ret); > > return kvm_skip_emulated_instruction(vcpu); > > > > base-commit: 675248928970d33f7fc8ca9851a170c98f4f1c4f >
