All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	mlevitsk@redhat.com, stable@vger.kernel.org
Subject: Re: [PATCH 1/3] KVM: x86: make vendor code check for all nested events
Date: Fri, 29 Apr 2022 17:35:28 +0000	[thread overview]
Message-ID: <Ymwh4PEZHDvWyR1f@google.com> (raw)
In-Reply-To: <0b554e22-6766-8299-287c-c40240c08536@redhat.com>

On Fri, Apr 29, 2022, Paolo Bonzini wrote:
> On 4/29/22 19:03, Sean Christopherson wrote:
> > This doesn't even compile...
> > 
> > arch/x86/kvm/vmx/nested.c: In function ‘vmx_has_nested_events’:
> > arch/x86/kvm/vmx/nested.c:3862:61: error: ‘vmx’ undeclared (first use in this function)
> >   3862 |         return nested_vmx_preemption_timer_pending(vcpu) || vmx->nested.mtf_pending;
> >        |                                                             ^~~
> > arch/x86/kvm/vmx/nested.c:3862:61: note: each undeclared identifier is reported only once for each function it appears in
> >    CC [M]  arch/x86/kvm/svm/svm_onhyperv.o
> > arch/x86/kvm/vmx/nested.c:3863:1: error: control reaches end of non-void function [-Werror=return-type]
> >   3863 | }
> >        | ^
> > cc1: all warnings being treated as errors
> >    LD [M]  arch/x86/kvm/kvm.o
> 
> Yeah, it doesn't.  Of course this will need a v2, also because there are
> failures in the vmx tests.

Heh, I suspected there would be failures, I was about to type up a response to
patch 3.  MTF is subtly relying on the call from kvm_vcpu_running() to inject
the event.

From: Sean Christopherson <seanjc@google.com>
Date: Fri, 29 Apr 2022 17:30:54 +0000
Subject: [PATCH] KVM: nVMX: Make an event request when pending an MTF nested
 VM-Exit

Set KVM_REQ_EVENT when MTF becomes pending to ensure that KVM will run
through inject_pending_event() and thus vmx_check_nested_events() prior
to re-entering the guest.  MTF currently works by virtue of KVM's hack
that calls kvm_check_nested_events() from kvm_vcpu_running(), but that
hack will be removed in the near future.

Fixes: 5ef8acbdd687 ("KVM: nVMX: Emulate MTF when performing instruction emulation")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
 arch/x86/kvm/vmx/vmx.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index d58b763df855..4c635bc08105 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1577,10 +1577,12 @@ static void vmx_update_emulated_instruction(struct kvm_vcpu *vcpu)
 	 */
 	if (nested_cpu_has_mtf(vmcs12) &&
 	    (!vcpu->arch.exception.pending ||
-	     vcpu->arch.exception.nr == DB_VECTOR))
+	     vcpu->arch.exception.nr == DB_VECTOR)) {
 		vmx->nested.mtf_pending = true;
-	else
+		kvm_make_request(KVM_REQ_EVENT, vcpu);
+	} else {
 		vmx->nested.mtf_pending = false;
+	}
 }

 static int vmx_skip_emulated_instruction(struct kvm_vcpu *vcpu)

base-commit: 39aa5903e8c407e5128c15aeabb0717b275b007e
--


  reply	other threads:[~2022-04-29 17:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27 17:37 [PATCH 0/2] KVM: x86: never write to memory from kvm_vcpu_check_block Paolo Bonzini
2022-04-27 17:37 ` [PATCH 1/3] KVM: x86: make vendor code check for all nested events Paolo Bonzini
2022-04-27 20:40   ` Maxim Levitsky
2022-04-29 18:40     ` Paolo Bonzini
2022-04-29 17:03   ` Sean Christopherson
2022-04-29 17:09     ` Paolo Bonzini
2022-04-29 17:35       ` Sean Christopherson [this message]
2022-04-27 17:37 ` [PATCH 2/3] KVM: x86: a vCPU with a pending triple fault is runnable Paolo Bonzini
2022-04-27 20:41   ` Maxim Levitsky
2022-04-27 17:37 ` [PATCH 3/3] KVM: x86: never write to memory from kvm_vcpu_check_block Paolo Bonzini
2022-04-27 20:42   ` Maxim Levitsky
2022-07-20  9:31 ` [PATCH 0/2] " Maxim Levitsky

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=Ymwh4PEZHDvWyR1f@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    /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.