From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 1/3] KVM: nVMX: unwind PDPTR load if processor triggers a nested VMFail
Date: Mon, 8 Jun 2026 20:31:33 -0700 [thread overview]
Message-ID: <aieJFWE3gQBwkS07@google.com> (raw)
In-Reply-To: <20260604160733.12555-2-pbonzini@redhat.com>
On Thu, Jun 04, 2026, Paolo Bonzini wrote:
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 4690a4d23709..d612a5d071fc 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -4947,6 +4947,7 @@ static inline u64 nested_vmx_get_vmcs01_guest_efer(struct vcpu_vmx *vmx)
>
> static void nested_vmx_restore_host_state(struct kvm_vcpu *vcpu)
> {
> + enum vm_entry_failure_code ignored;
> struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
> struct vcpu_vmx *vmx = to_vmx(vcpu);
> struct vmx_msr_entry g, h;
> @@ -4984,20 +4985,19 @@ static void nested_vmx_restore_host_state(struct kvm_vcpu *vcpu)
> vmx_set_cr4(vcpu, vmcs_readl(CR4_READ_SHADOW));
>
> nested_ept_uninit_mmu_context(vcpu);
> - vcpu->arch.cr3 = vmcs_readl(GUEST_CR3);
> - kvm_register_mark_available(vcpu, VCPU_REG_CR3);
>
> /*
> - * Use ept_save_pdptrs(vcpu) to load the MMU's cached PDPTRs
> - * from vmcs01 (if necessary). The PDPTRs are not loaded on
> - * VMFail, like everything else we just need to ensure our
> - * software model is up-to-date.
> + * Now that nested EPT has been disabled, load the MMU's CR3 and
> + * possibly PDPTRs from vmcs01 (if necessary). This should not
> + * happen for VMFail, but we get here if the check was caught by
> + * the processor and therefore the guest CR3 was loaded prematurely.
> */
> + kvm_mmu_unload(vcpu);
> + if (nested_vmx_load_cr3(vcpu, vmcs_readl(GUEST_CR3), false, !enable_ept, &ignored))
> + nested_vmx_abort(vcpu, VMX_ABORT_LOAD_HOST_PDPTE_FAIL);
This isn't quite correct either. I mean, none of this is architecturally correct,
but this is less correct than the other incorrect code here :-)
To do this "right", KVM should snapshot the PDPTRs and shove them into the MMU,
without touching guest memory.
On a very related topic, I have a patch to stash CR3 in software instead of
abusing vmcs01.GUEST_CR3, as KVM fails to restore vmcs01.GUEST_CR3 to its proper
state if nested_vmx_enter_non_root_mode() bails after clobbering vmcs01.GUEST_CR3,
but before loading guest state. We could probably do the same thing for PDPTRs?
https://lore.kernel.org/all/20260603223418.1720035-3-seanjc@google.com
> if (enable_ept && is_pae_paging(vcpu))
> ept_save_pdptrs(vcpu);
>
> - kvm_mmu_reset_context(vcpu);
> -
> /*
> * This nasty bit of open coding is a compromise between blindly
> * loading L1's MSRs using the exit load lists (incorrect emulation
> --
> 2.52.0
>
>
next prev parent reply other threads:[~2026-06-09 3:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-04 16:07 [PATCH 0/3] KVM: harden and cleanup PDPTR load on forced L1 reload Paolo Bonzini
2026-06-04 16:07 ` [PATCH 1/3] KVM: nVMX: unwind PDPTR load if processor triggers a nested VMFail Paolo Bonzini
2026-06-09 3:31 ` Sean Christopherson [this message]
2026-06-04 16:07 ` [PATCH 2/3] KVM: MMU: unconditionally clear MMIO cache on root rebuild Paolo Bonzini
2026-06-04 16:07 ` [PATCH 3/3] KVM: nVMX: remove unnecessary unload on processor-detected VMFail 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=aieJFWE3gQBwkS07@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox