Re: [PATCH v3 1/2] KVM: x86: Check hypercall's exit to userspace generically

[Sean Christopherson <seanjc@google.com>]

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@linux.intel.com>
> > > Reviewed-by: Kai Huang <kai.huang@intel.com>
> > > ---
> > >   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
>