All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano De Venuto <stefano.devenuto99@gmail.com>
To: linux-kernel@vger.kernel.org
Cc: pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com,
	wanpengli@tencent.com, jmattson@google.com, x86@kernel.org,
	hpa@zytor.com, kvm@vger.kernel.org, rostedt@goodmis.org,
	y.karadz@gmail.com,
	Stefano De Venuto <stefano.devenuto99@gmail.com>,
	Dario Faggioli <dfaggioli@suse.com>
Subject: [PATCH] Move VMEnter and VMExit tracepoints closer to the actual event
Date: Wed, 19 May 2021 20:23:03 +0200	[thread overview]
Message-ID: <20210519182303.2790-1-stefano.devenuto99@gmail.com> (raw)

The kvm_entry and kvm_exit tracepoints are still quite far from the
actual VMEnters/VMExits. This means that in a trace we can find host
events after a kvm_entry event and before a kvm_exit one, as in this
example:

           trace.dat:  CPU 0/KVM-4594  [001]  2.167191: kvm_entry:
           trace.dat:  CPU 0/KVM-4594  [001]  2.167192: write_msr: 48, value 0
           trace.dat:  CPU 0/KVM-4594  [001]  2.167192: rcu_utilization: Start context switch
           trace.dat:  CPU 0/KVM-4594  [001]  2.167192: rcu_utilization: End context switch
trace-tumbleweed.dat:     <idle>-0     [000]  2.167196: hrtimer_cancel:
trace-tumbleweed.dat:     <idle>-0     [000]  2.167197: hrtimer_expire_entry:
trace-tumbleweed.dat:     <idle>-0     [000]  2.167201: hrtimer_expire_exit:
trace-tumbleweed.dat:     <idle>-0     [000]  2.167201: hrtimer_start:
           trace.dat:  CPU 0/KVM-4594  [001]  2.167203: read_msr: 48, value 0
           trace.dat:  CPU 0/KVM-4594  [001]  2.167203: write_msr: 48, value 4
           trace.dat:  CPU 0/KVM-4594  [001]  2.167204: kvm_exit: 

This patch moves the tracepoints closer to the events, for both Intel
and AMD, so that a combined host-guest trace will offer a more
realistic representation of what is really happening, as shown here:

           trace.dat:  CPU 0/KVM-2553  [000]  2.190290: write_msr: 48, value 0
           trace.dat:  CPU 0/KVM-2553  [000]  2.190290: rcu_utilization: Start context switch
           trace.dat:  CPU 0/KVM-2553  [000]  2.190290: rcu_utilization: End context switch
           trace.dat:  CPU 0/KVM-2553  [000]  2.190290: kvm_entry:
trace-tumbleweed.dat:     <idle>-0     [000]  2.190290: write_msr:
trace-tumbleweed.dat:     <idle>-0     [000]  2.190290: cpu_idle:
           trace.dat:  CPU 0/KVM-2553  [000]  2.190291: kvm_exit:
           trace.dat:  CPU 0/KVM-2553  [000]  2.190291: read_msr: 48, value 0
           trace.dat:  CPU 0/KVM-2553  [000]  2.190291: write_msr: 48, value 4 

Signed-off-by: Stefano De Venuto <stefano.devenuto99@gmail.com>
Signed-off-by: Dario Faggioli <dfaggioli@suse.com>
---
 arch/x86/kvm/svm/svm.c |  8 ++++----
 arch/x86/kvm/vmx/vmx.c | 10 +++++-----
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 05eca131eaf2..c77d4866e239 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3275,8 +3275,6 @@ static int handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
 	struct kvm_run *kvm_run = vcpu->run;
 	u32 exit_code = svm->vmcb->control.exit_code;
 
-	trace_kvm_exit(exit_code, vcpu, KVM_ISA_SVM);
-
 	/* SEV-ES guests must use the CR write traps to track CR registers. */
 	if (!sev_es_guest(vcpu->kvm)) {
 		if (!svm_is_intercept(svm, INTERCEPT_CR0_WRITE))
@@ -3707,6 +3705,8 @@ static noinstr void svm_vcpu_enter_exit(struct kvm_vcpu *vcpu)
 
 	kvm_guest_enter_irqoff();
 
+	trace_kvm_entry(vcpu);
+
 	if (sev_es_guest(vcpu->kvm)) {
 		__svm_sev_es_vcpu_run(vmcb_pa);
 	} else {
@@ -3725,6 +3725,8 @@ static noinstr void svm_vcpu_enter_exit(struct kvm_vcpu *vcpu)
 		vmload(__sme_page_pa(sd->save_area));
 	}
 
+	trace_kvm_exit(svm->vmcb->control.exit_code, vcpu, KVM_ISA_SVM);
+
 	kvm_guest_exit_irqoff();
 }
 
@@ -3732,8 +3734,6 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct kvm_vcpu *vcpu)
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
 
-	trace_kvm_entry(vcpu);
-
 	svm->vmcb->save.rax = vcpu->arch.regs[VCPU_REGS_RAX];
 	svm->vmcb->save.rsp = vcpu->arch.regs[VCPU_REGS_RSP];
 	svm->vmcb->save.rip = vcpu->arch.regs[VCPU_REGS_RIP];
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 4bceb5ca3a89..33c732101b83 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -6661,6 +6661,8 @@ static noinstr void vmx_vcpu_enter_exit(struct kvm_vcpu *vcpu,
 {
 	kvm_guest_enter_irqoff();
 
+	trace_kvm_entry(vcpu);
+
 	/* L1D Flush includes CPU buffer clear to mitigate MDS */
 	if (static_branch_unlikely(&vmx_l1d_should_flush))
 		vmx_l1d_flush(vcpu);
@@ -6675,6 +6677,9 @@ static noinstr void vmx_vcpu_enter_exit(struct kvm_vcpu *vcpu,
 
 	vcpu->arch.cr2 = native_read_cr2();
 
+	vmx->exit_reason.full = vmcs_read32(VM_EXIT_REASON);
+	trace_kvm_exit(vmx->exit_reason.full, vcpu, KVM_ISA_VMX);
+
 	kvm_guest_exit_irqoff();
 }
 
@@ -6693,8 +6698,6 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
 	if (vmx->emulation_required)
 		return EXIT_FASTPATH_NONE;
 
-	trace_kvm_entry(vcpu);
-
 	if (vmx->ple_window_dirty) {
 		vmx->ple_window_dirty = false;
 		vmcs_write32(PLE_WINDOW, vmx->ple_window);
@@ -6814,15 +6817,12 @@ static fastpath_t vmx_vcpu_run(struct kvm_vcpu *vcpu)
 		return EXIT_FASTPATH_NONE;
 	}
 
-	vmx->exit_reason.full = vmcs_read32(VM_EXIT_REASON);
 	if (unlikely((u16)vmx->exit_reason.basic == EXIT_REASON_MCE_DURING_VMENTRY))
 		kvm_machine_check();
 
 	if (likely(!vmx->exit_reason.failed_vmentry))
 		vmx->idt_vectoring_info = vmcs_read32(IDT_VECTORING_INFO_FIELD);
 
-	trace_kvm_exit(vmx->exit_reason.full, vcpu, KVM_ISA_VMX);
-
 	if (unlikely(vmx->exit_reason.failed_vmentry))
 		return EXIT_FASTPATH_NONE;
 
-- 
2.31.1


             reply	other threads:[~2021-05-19 18:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19 18:23 Stefano De Venuto [this message]
2021-05-20  6:05 ` [PATCH] Move VMEnter and VMExit tracepoints closer to the actual event Dario Faggioli
2021-05-20  7:21 ` Thomas Gleixner
2021-05-21  7:13   ` Dario Faggioli
2021-05-20 15:32 ` Sean Christopherson
2021-05-20 16:18   ` Paolo Bonzini
2021-05-21  7:58     ` Dario Faggioli
2021-05-28 16:55     ` Dario Faggioli
2021-05-28 16:57       ` Paolo Bonzini
2021-05-21  7:51   ` Dario Faggioli
2021-05-25 16:20     ` Sean Christopherson
2021-05-28 17:03       ` Dario Faggioli

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=20210519182303.2790-1-stefano.devenuto99@gmail.com \
    --to=stefano.devenuto99@gmail.com \
    --cc=dfaggioli@suse.com \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    --cc=y.karadz@gmail.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.