[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZyOeMJ3BtI_h136q@google.com>
Date: Thu, 31 Oct 2024 08:11:44 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, pbonzini@...hat.com,
isaku.yamahata@...el.com, rick.p.edgecombe@...el.com, kai.huang@...el.com,
yuan.yao@...ux.intel.com, xiaoyao.li@...el.com
Subject: Re: [PATCH v3 1/2] KVM: x86: Check hypercall's exit to userspace generically
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@...ux.intel.com>
> > > Reviewed-by: Kai Huang <kai.huang@...el.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
>
Powered by blists - more mailing lists