From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
x86@kernel.org, Borislav Petkov <bp@alien8.de>,
Paolo Bonzini <pbonzini@redhat.com>,
Ingo Molnar <mingo@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Joerg Roedel <joro@8bytes.org>,
Wanpeng Li <wanpengli@tencent.com>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, Jim Mattson <jmattson@google.com>
Subject: Re: [PATCH v2 2/3] KVM: nVMX: add kvm_nested_vmlaunch_resume tracepoint
Date: Thu, 14 Jan 2021 16:14:07 -0800 [thread overview]
Message-ID: <YADeT8+fssKw3SSi@google.com> (raw)
In-Reply-To: <20210114205449.8715-3-mlevitsk@redhat.com>
On Thu, Jan 14, 2021, Maxim Levitsky wrote:
> This is very helpful for debugging nested VMX issues.
>
> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> ---
> arch/x86/kvm/trace.h | 30 ++++++++++++++++++++++++++++++
> arch/x86/kvm/vmx/nested.c | 6 ++++++
> arch/x86/kvm/x86.c | 1 +
> 3 files changed, 37 insertions(+)
>
> diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
> index 2de30c20bc264..663d1b1d8bf64 100644
> --- a/arch/x86/kvm/trace.h
> +++ b/arch/x86/kvm/trace.h
> @@ -554,6 +554,36 @@ TRACE_EVENT(kvm_nested_vmrun,
> __entry->npt ? "on" : "off")
> );
>
> +
> +/*
> + * Tracepoint for nested VMLAUNCH/VMRESUME
VM-Enter, as below.
> + */
> +TRACE_EVENT(kvm_nested_vmlaunch_resume,
s/vmlaunc_resume/vmenter, both for consistency with other code and so that it
can sanely be reused by SVM. IMO, trace_kvm_entry is wrong :-).
> + TP_PROTO(__u64 rip, __u64 vmcs, __u64 nested_rip,
> + __u32 entry_intr_info),
> + TP_ARGS(rip, vmcs, nested_rip, entry_intr_info),
> +
> + TP_STRUCT__entry(
> + __field( __u64, rip )
> + __field( __u64, vmcs )
> + __field( __u64, nested_rip )
> + __field( __u32, entry_intr_info )
> + ),
> +
> + TP_fast_assign(
> + __entry->rip = rip;
> + __entry->vmcs = vmcs;
> + __entry->nested_rip = nested_rip;
> + __entry->entry_intr_info = entry_intr_info;
> + ),
> +
> + TP_printk("rip: 0x%016llx vmcs: 0x%016llx nrip: 0x%016llx "
> + "entry_intr_info: 0x%08x",
> + __entry->rip, __entry->vmcs, __entry->nested_rip,
> + __entry->entry_intr_info)
> +);
> +
> +
> TRACE_EVENT(kvm_nested_intercepts,
> TP_PROTO(__u16 cr_read, __u16 cr_write, __u32 exceptions,
> __u32 intercept1, __u32 intercept2, __u32 intercept3),
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 776688f9d1017..cd51b66480d52 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -3327,6 +3327,12 @@ enum nvmx_vmentry_status nested_vmx_enter_non_root_mode(struct kvm_vcpu *vcpu,
> !(vmcs12->vm_entry_controls & VM_ENTRY_LOAD_BNDCFGS))
> vmx->nested.vmcs01_guest_bndcfgs = vmcs_read64(GUEST_BNDCFGS);
>
> + trace_kvm_nested_vmlaunch_resume(kvm_rip_read(vcpu),
Hmm, won't this RIP be wrong for the migration case? I.e. it'll be L2, not L1
as is the case for the "true" nested VM-Enter path.
> + vmx->nested.current_vmptr,
> + vmcs12->guest_rip,
> + vmcs12->vm_entry_intr_info_field);
The placement is a bit funky. I assume you put it here so that calls from
vmx_set_nested_state() also get traced. But, that also means
vmx_pre_leave_smm() will get traced, and it also creates some weirdness where
some nested VM-Enters that VM-Fail will get traced, but others will not.
Tracing vmx_pre_leave_smm() isn't necessarily bad, but it could be confusing,
especially if the debugger looks up the RIP and sees RSM. Ditto for the
migration case.
Not sure what would be a good answer.
> +
> +
> /*
> * Overwrite vmcs01.GUEST_CR3 with L1's CR3 if EPT is disabled *and*
> * nested early checks are disabled. In the event of a "late" VM-Fail,
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index a480804ae27a3..7c6e94e32100e 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -11562,6 +11562,7 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_inj_virq);
> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_page_fault);
> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_msr);
> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_cr);
> +EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_vmlaunch_resume);
> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_vmrun);
> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_vmexit);
> EXPORT_TRACEPOINT_SYMBOL_GPL(kvm_nested_vmexit_inject);
> --
> 2.26.2
>
next prev parent reply other threads:[~2021-01-15 0:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-14 20:54 [PATCH v2 0/3] VMX: more nested fixes Maxim Levitsky
2021-01-14 20:54 ` [PATCH v2 1/3] KVM: nVMX: Always call sync_vmcs02_to_vmcs12_rare on migration Maxim Levitsky
2021-01-14 23:58 ` Sean Christopherson
2021-01-21 14:59 ` Paolo Bonzini
2021-01-14 20:54 ` [PATCH v2 2/3] KVM: nVMX: add kvm_nested_vmlaunch_resume tracepoint Maxim Levitsky
2021-01-15 0:14 ` Sean Christopherson [this message]
2021-01-15 13:48 ` Paolo Bonzini
2021-01-15 16:30 ` Sean Christopherson
2021-01-21 17:00 ` Maxim Levitsky
2021-01-21 16:58 ` Maxim Levitsky
2021-01-21 17:02 ` Maxim Levitsky
2021-01-14 20:54 ` [PATCH v2 3/3] KVM: VMX: read idt_vectoring_info a bit earlier Maxim Levitsky
2021-01-15 0:29 ` Sean Christopherson
2021-01-21 17:04 ` Maxim Levitsky
2021-01-21 15:00 ` [PATCH v2 0/3] VMX: more nested fixes 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=YADeT8+fssKw3SSi@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--cc=x86@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.