From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 1/3] KVM: x86: check_nested_events is never NULL
Date: Mon, 20 Apr 2020 10:47:16 +0200 [thread overview]
Message-ID: <87a736tugb.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20200417164413.71885-2-pbonzini@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> Both Intel and AMD now implement it, so there is no need to check if the
> callback is implemented.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> arch/x86/kvm/x86.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 59958ce2b681..0492baeb78ab 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7699,7 +7699,7 @@ static int inject_pending_event(struct kvm_vcpu *vcpu)
> * from L2 to L1 due to pending L1 events which require exit
> * from L2 to L1.
> */
> - if (is_guest_mode(vcpu) && kvm_x86_ops.check_nested_events) {
> + if (is_guest_mode(vcpu)) {
> r = kvm_x86_ops.check_nested_events(vcpu);
> if (r != 0)
> return r;
> @@ -7761,7 +7761,7 @@ static int inject_pending_event(struct kvm_vcpu *vcpu)
> * proposal and current concerns. Perhaps we should be setting
> * KVM_REQ_EVENT only on certain events and not unconditionally?
> */
> - if (is_guest_mode(vcpu) && kvm_x86_ops.check_nested_events) {
> + if (is_guest_mode(vcpu)) {
> r = kvm_x86_ops.check_nested_events(vcpu);
> if (r != 0)
> return r;
> @@ -8527,7 +8527,7 @@ static inline int vcpu_block(struct kvm *kvm, struct kvm_vcpu *vcpu)
>
> static inline bool kvm_vcpu_running(struct kvm_vcpu *vcpu)
> {
> - if (is_guest_mode(vcpu) && kvm_x86_ops.check_nested_events)
> + if (is_guest_mode(vcpu))
> kvm_x86_ops.check_nested_events(vcpu);
>
> return (vcpu->arch.mp_state == KVM_MP_STATE_RUNNABLE &&
While the callback is implemented for both VMX and SVM, it can still be
NULL when !nested (thus patch subject is a bit misleading) but
is_guest_mode() implies this is not the case.
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
--
Vitaly
next prev parent reply other threads:[~2020-04-20 8:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 16:44 [PATCH 0/3] KVM: x86: move nested-related kvm_x86_ops to a separate struct Paolo Bonzini
2020-04-17 16:44 ` [PATCH 1/3] KVM: x86: check_nested_events is never NULL Paolo Bonzini
2020-04-20 8:47 ` Vitaly Kuznetsov [this message]
2020-04-17 16:44 ` [PATCH 2/3] KVM: eVMCS: check if nesting is enabled Paolo Bonzini
2020-04-20 8:49 ` Vitaly Kuznetsov
2020-04-17 16:44 ` [PATCH 3/3] KVM: x86: move nested-related kvm_x86_ops to a separate struct Paolo Bonzini
2020-04-20 8:54 ` Vitaly Kuznetsov
2020-04-17 19:05 ` [PATCH 0/3] " Peter Xu
2020-04-17 19:11 ` Sean Christopherson
2020-04-18 9:55 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a736tugb.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.