From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Kai Huang <kai.huang@intel.com>, Yan Zhao <yan.y.zhao@intel.com>,
Binbin Wu <binbin.wu@linux.intel.com>
Subject: Re: [PATCH v3 1/3] KVM: x86/mmu: Use KVM's max TDP level to determine need for 32-bit TDP root
Date: Wed, 9 Sep 2026 22:08:46 +0800 [thread overview]
Message-ID: <1e311e04-6632-40f8-b73e-69773b9201aa@intel.com> (raw)
In-Reply-To: <20260902230932.2760127-2-seanjc@google.com>
On 9/3/2026 7:09 AM, Sean Christopherson wrote:
> When checking to see if KVM needs to allocate a TDP PAE root that's 32-bit
> addressable, query KVM's overall max TDP level, not the vCPU-specific TDP
> level, as the logic is specific to using NPT on 32-bit hosts. Querying the
> vCPU's alleged TDP level is flawed and confusing, as KVM selects between
> 4-level vs. 5-level based on the guest's MAXPHYADDR, and MAXPHYADDR isn't
> yet configured (via CPUID) when the vCPU is being created.
>
> I.e. as is, it would *appear* that KVM is violating its own rules with
> respect to changing guest CPUID (see kvm_mmu_after_set_cpuid()). In
> practice, the flaw is benign as the goal is purely to see if KVM needs to
> use PAE-paging; whether KVM will use 4-level vs. 5-level is irrelevant.
>
> More importantly, avoiding kvm_mmu_get_tdp_level() during vCPU creation
> will allow hardening KVM's handling of S-EPT mirror root level.
>
> For all intents and purposes, no functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
> ---
> arch/x86/kvm/mmu/mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 064ecc33b926..c9a684151420 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -6834,7 +6834,7 @@ static int __kvm_mmu_create(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, struct k
> * other exception is for shadowing L1's 32-bit or PAE NPT on 64-bit
> * KVM; that horror is handled on-demand by mmu_alloc_special_roots().
> */
> - if (tdp_enabled && kvm_mmu_get_tdp_level(vcpu) > PT32E_ROOT_LEVEL)
> + if (tdp_enabled && kvm_mmu_get_max_tdp_level() > PT32E_ROOT_LEVEL)
> return 0;
>
> page = alloc_page(GFP_KERNEL_ACCOUNT | __GFP_DMA32);
next prev parent reply other threads:[~2026-09-09 14:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 23:09 [PATCH v3 0/3] KVM: VMX: Explicitly track TDX VMs' root level Sean Christopherson
2026-09-02 23:09 ` [PATCH v3 1/3] KVM: x86/mmu: Use KVM's max TDP level to determine need for 32-bit TDP root Sean Christopherson
2026-09-09 14:08 ` Xiaoyao Li [this message]
2026-09-02 23:09 ` [PATCH v3 2/3] KVM: VMX: Explicitly track TDX VMs' root level instead of guessing it from CPUID Sean Christopherson
2026-09-09 14:16 ` Xiaoyao Li
2026-09-02 23:09 ` [PATCH v3 3/3] KVM: VMX: Drop TDX_SHARED_BIT_PWL_{4,5} and dedup related code Sean Christopherson
2026-09-09 14:18 ` Xiaoyao Li
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=1e311e04-6632-40f8-b73e-69773b9201aa@intel.com \
--to=xiaoyao.li@intel.com \
--cc=binbin.wu@linux.intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=yan.y.zhao@intel.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.