From: Sean Christopherson <seanjc@google.com>
To: David Edmondson <david.edmondson@oracle.com>
Cc: linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Joerg Roedel <joro@8bytes.org>,
x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Ingo Molnar <mingo@redhat.com>, Jim Mattson <jmattson@google.com>,
Borislav Petkov <bp@alien8.de>,
Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH v2 1/3] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid
Date: Tue, 23 Feb 2021 14:51:19 -0800 [thread overview]
Message-ID: <YDWG51Io0VJEBHGg@google.com> (raw)
In-Reply-To: <20210219144632.2288189-2-david.edmondson@oracle.com>
On Fri, Feb 19, 2021, David Edmondson wrote:
> If the VM entry/exit controls for loading/saving MSR_EFER are either
> not available (an older processor or explicitly disabled) or not
> used (host and guest values are the same), reading GUEST_IA32_EFER
> from the VMCS returns an inaccurate value.
>
> Because of this, in dump_vmcs() don't use GUEST_IA32_EFER to decide
> whether to print the PDPTRs - do so if the EPT is in use and CR4.PAE
> is set.
This isn't necessarily correct either. In a way, it's less correct as PDPTRs
are more likely to be printed when they shouldn't, assuming most guests are
64-bit guests. It's annoying to calculate the effective guest EFER, but so
awful that it's worth risking confusion over PDTPRs.
> Fixes: 4eb64dce8d0a ("KVM: x86: dump VMCS on invalid entry")
> Signed-off-by: David Edmondson <david.edmondson@oracle.com>
> ---
> arch/x86/kvm/vmx/vmx.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index eb69fef57485..818051c9fa10 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -5759,7 +5759,6 @@ void dump_vmcs(void)
> u32 vmentry_ctl, vmexit_ctl;
> u32 cpu_based_exec_ctrl, pin_based_exec_ctrl, secondary_exec_control;
> unsigned long cr4;
> - u64 efer;
>
> if (!dump_invalid_vmcs) {
> pr_warn_ratelimited("set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.\n");
> @@ -5771,7 +5770,6 @@ void dump_vmcs(void)
> cpu_based_exec_ctrl = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
> pin_based_exec_ctrl = vmcs_read32(PIN_BASED_VM_EXEC_CONTROL);
> cr4 = vmcs_readl(GUEST_CR4);
> - efer = vmcs_read64(GUEST_IA32_EFER);
> secondary_exec_control = 0;
> if (cpu_has_secondary_exec_ctrls())
> secondary_exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
> @@ -5784,8 +5782,7 @@ void dump_vmcs(void)
> cr4, vmcs_readl(CR4_READ_SHADOW), vmcs_readl(CR4_GUEST_HOST_MASK));
> pr_err("CR3 = 0x%016lx\n", vmcs_readl(GUEST_CR3));
> if ((secondary_exec_control & SECONDARY_EXEC_ENABLE_EPT) &&
> - (cr4 & X86_CR4_PAE) && !(efer & EFER_LMA))
> - {
> + (cr4 & X86_CR4_PAE)) {
> pr_err("PDPTR0 = 0x%016llx PDPTR1 = 0x%016llx\n",
> vmcs_read64(GUEST_PDPTR0), vmcs_read64(GUEST_PDPTR1));
> pr_err("PDPTR2 = 0x%016llx PDPTR3 = 0x%016llx\n",
> @@ -5811,7 +5808,8 @@ void dump_vmcs(void)
> if ((vmexit_ctl & (VM_EXIT_SAVE_IA32_PAT | VM_EXIT_SAVE_IA32_EFER)) ||
> (vmentry_ctl & (VM_ENTRY_LOAD_IA32_PAT | VM_ENTRY_LOAD_IA32_EFER)))
> pr_err("EFER = 0x%016llx PAT = 0x%016llx\n",
> - efer, vmcs_read64(GUEST_IA32_PAT));
> + vmcs_read64(GUEST_IA32_EFER),
> + vmcs_read64(GUEST_IA32_PAT));
> pr_err("DebugCtl = 0x%016llx DebugExceptions = 0x%016lx\n",
> vmcs_read64(GUEST_IA32_DEBUGCTL),
> vmcs_readl(GUEST_PENDING_DBG_EXCEPTIONS));
> --
> 2.30.0
>
next prev parent reply other threads:[~2021-02-23 22:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-19 14:46 [PATCH v2 0/3] KVM: x86: dump_vmcs: don't assume GUEST_IA32_EFER, show MSR autoloads/autosaves David Edmondson
2021-02-19 14:46 ` [PATCH v2 1/3] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid David Edmondson
2021-02-23 22:51 ` Sean Christopherson [this message]
2021-02-23 23:13 ` Jim Mattson
2021-02-23 23:41 ` Sean Christopherson
2021-02-24 13:30 ` David Edmondson
2021-02-23 23:18 ` Jim Mattson
2021-02-19 14:46 ` [PATCH v2 2/3] KVM: x86: dump_vmcs should not conflate EFER and PAT presence in VMCS David Edmondson
2021-02-23 22:58 ` Sean Christopherson
2021-02-24 13:31 ` David Edmondson
2021-02-19 14:46 ` [PATCH v2 3/3] KVM: x86: dump_vmcs should include the autoload/autostore MSR lists David Edmondson
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=YDWG51Io0VJEBHGg@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=david.edmondson@oracle.com \
--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=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.