| Message ID | 20220622004924.155191-4-kechenl@nvidia.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: x86: add per-vCPU exits disable capability | expand |
On Tue, Jun 21, 2022, Kechen Lu wrote: > From: Sean Christopherson <seanjc@google.com> > > Reject KVM_CAP_X86_DISABLE_EXITS if userspace attempts to disable MWAIT > exits and KVM previously reported (via KVM_CHECK_EXTENSION) that MWAIT is > not allowed in guest, e.g. because it's not supported or the CPU doesn't > have an aways-running APIC timer. > > Fixes: 4d5422cea3b6 ("KVM: X86: Provide a capability to disable MWAIT intercepts") > Signed-off-by: Sean Christopherson <seanjc@google.com> > Co-developed-by: Kechen Lu <kechenl@nvidia.com> Needs your SOB. > Suggested-by: Chao Gao <chao.gao@intel.com> For code review feedback of this nature, adding Suggested-by isn't appropriate. Suggested-by is for when the idea of the patch itself was suggested by someone, where as Chao's feedback was a purely mechanical change. > --- > arch/x86/kvm/x86.c | 20 +++++++++++++------- > 1 file changed, 13 insertions(+), 7 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index b419b258ed90..6ec01362a7d8 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -4199,6 +4199,16 @@ static inline bool kvm_can_mwait_in_guest(void) > boot_cpu_has(X86_FEATURE_ARAT); > } > > +static u64 kvm_get_allowed_disable_exits(void) > +{ > + u64 r = KVM_X86_DISABLE_VALID_EXITS; In v3 I "voted" to keep the switch to KVM_X86_DISABLE_VALID_EXITS in the next patch[*], but seeing the result I 100% agree it's better to handle it here since the "enable" patch previously used KVM_X86_DISABLE_VALID_EXITS. [*] https://lore.kernel.org/all/Ytg428sleo7uMRQt@google.com > + > + if(!kvm_can_mwait_in_guest()) Space after the "if".
> -----Original Message----- > From: Sean Christopherson <seanjc@google.com> > Sent: Wednesday, July 20, 2022 10:54 AM > To: Kechen Lu <kechenl@nvidia.com> > Cc: kvm@vger.kernel.org; pbonzini@redhat.com; chao.gao@intel.com; > vkuznets@redhat.com; Somdutta Roy <somduttar@nvidia.com>; linux- > kernel@vger.kernel.org > Subject: Re: [RFC PATCH v4 3/7] KVM: x86: Reject disabling of MWAIT > interception when not allowed > > External email: Use caution opening links or attachments > > > On Tue, Jun 21, 2022, Kechen Lu wrote: > > From: Sean Christopherson <seanjc@google.com> > > > > Reject KVM_CAP_X86_DISABLE_EXITS if userspace attempts to disable > > MWAIT exits and KVM previously reported (via KVM_CHECK_EXTENSION) > that > > MWAIT is not allowed in guest, e.g. because it's not supported or the > > CPU doesn't have an aways-running APIC timer. > > > > Fixes: 4d5422cea3b6 ("KVM: X86: Provide a capability to disable MWAIT > > intercepts") > > Signed-off-by: Sean Christopherson <seanjc@google.com> > > Co-developed-by: Kechen Lu <kechenl@nvidia.com> > > Needs your SOB. > Ack! > > Suggested-by: Chao Gao <chao.gao@intel.com> > > For code review feedback of this nature, adding Suggested-by isn't > appropriate. > Suggested-by is for when the idea of the patch itself was suggested by > someone, where as Chao's feedback was a purely mechanical change. > Sure I see. > > --- > > arch/x86/kvm/x86.c | 20 +++++++++++++------- > > 1 file changed, 13 insertions(+), 7 deletions(-) > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index > > b419b258ed90..6ec01362a7d8 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -4199,6 +4199,16 @@ static inline bool > kvm_can_mwait_in_guest(void) > > boot_cpu_has(X86_FEATURE_ARAT); } > > > > +static u64 kvm_get_allowed_disable_exits(void) > > +{ > > + u64 r = KVM_X86_DISABLE_VALID_EXITS; > > In v3 I "voted" to keep the switch to KVM_X86_DISABLE_VALID_EXITS in the > next patch[*], but seeing the result I 100% agree it's better to handle it here > since the "enable" patch previously used KVM_X86_DISABLE_VALID_EXITS. > Yes, I agree, handling here makes sense. > [*] https://lore.kernel.org/all/Ytg428sleo7uMRQt@google.com > > > + > > + if(!kvm_can_mwait_in_guest()) > > Space after the "if". Ack!
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index b419b258ed90..6ec01362a7d8 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -4199,6 +4199,16 @@ static inline bool kvm_can_mwait_in_guest(void) boot_cpu_has(X86_FEATURE_ARAT); } +static u64 kvm_get_allowed_disable_exits(void) +{ + u64 r = KVM_X86_DISABLE_VALID_EXITS; + + if(!kvm_can_mwait_in_guest()) + r &= ~KVM_X86_DISABLE_EXITS_MWAIT; + + return r; +} + static int kvm_ioctl_get_supported_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 __user *cpuid_arg) { @@ -4318,10 +4328,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) r = KVM_CLOCK_VALID_FLAGS; break; case KVM_CAP_X86_DISABLE_EXITS: - r |= KVM_X86_DISABLE_EXITS_HLT | KVM_X86_DISABLE_EXITS_PAUSE | - KVM_X86_DISABLE_EXITS_CSTATE; - if(kvm_can_mwait_in_guest()) - r |= KVM_X86_DISABLE_EXITS_MWAIT; + r |= kvm_get_allowed_disable_exits(); break; case KVM_CAP_X86_SMM: /* SMBASE is usually relocated above 1M on modern chipsets, @@ -6003,15 +6010,14 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, break; case KVM_CAP_X86_DISABLE_EXITS: r = -EINVAL; - if (cap->args[0] & ~KVM_X86_DISABLE_VALID_EXITS) + if (cap->args[0] & ~kvm_get_allowed_disable_exits()) break; mutex_lock(&kvm->lock); if (kvm->created_vcpus) goto disable_exits_unlock; - if ((cap->args[0] & KVM_X86_DISABLE_EXITS_MWAIT) && - kvm_can_mwait_in_guest()) + if (cap->args[0] & KVM_X86_DISABLE_EXITS_MWAIT) kvm->arch.mwait_in_guest = true; if (cap->args[0] & KVM_X86_DISABLE_EXITS_HLT) kvm->arch.hlt_in_guest = true;