Re: [PATCH] KVM: VMX: Explicitly track TDX VMs' root level instead of guessing it from CPUID

[Sean Christopherson <seanjc@google.com>]

On Wed, Aug 19, 2026, Rick P Edgecombe wrote:
> On Fri, 2026-08-14 at 15:45 -0700, Sean Christopherson wrote:
> > Explicitly track the root level for TDX VMs instead of trying to infer the
> > depth of the paging tree based on an individual vCPU's CPUID information.
> > Applying KVM's existing logic to select the root level to TDX is flawed as
> > nothing *requires* userspace to fill in the correct guest.MAXPHYADDR for a
> > vCPU's CPUID.  Guessing at the correct root level is also ridiculous given
> > that userspace has already told KVM the root level during TD initialization.
> > 
> > Relying on userspace to set the expected/correct CPUID lets a misbehaving
> > userspace trip the KVM_BUG_ON() in tdx_load_mmu_pgd() by configuring guest
> > CPUID to use an "incorrect" guest.MAXPHYADDR.
> 
> Hmm, yea. But to me the text is a little ambiguous what "configuring guest
> CPUID" means. There are the two configurations of CPUID that happen and the goof
> was due to forgetting that there is no enforcement between the first "directly
> configurable bits" (where "userspace has already told KVM the root level during
> TD initialization" happens), and the second that happens via normal SET_CPUID.
> 
> Doing a KVM_BUG_ON() if tdx code sees a different level than what was processed
> in setup_tdparams_eptp_controls() seems good to me.
> 
> > 
> > Keep gfn_direct_bits even though it can be trivially derived from
> > mirror_root_level as saving a whole eight bytes per VM is meaningless, and
> > the value is queried fairly often and in hot paths.
> 
> gfn_direct_bits comes directly from the the initial configuration, so why do we
> need to add mirror_root_level in this patch? The old code calculated shared bit
> with a conditional, so we could easily compute level with an inverted
> conditional. The mirror_root_level caching is then a separate
> cleanup/enhancments.
> 
> Ohhh, because to calculate it kvm_mmu_get_tdp_level() would embed some TDX
> specifics there.
> 
> Wait, no, this knowledge embeds in kvm_mmu_set_mirror_root_level() anyway. So
> I'd think to just have the below. 

I started with that, but I didn't like bleeding that level of detail into the
MMU.  Or rather, I didn't like baking in the assumption that there is exactly
one "direct bits", that the one bit is a pivot between normal and mirror root,
and that the pivot bit is the most significant bit of the effective GPA space.

On the other hand, the MMU already knows about mirror roots, and needs to know
that mirror roots can have predetermined levels, so explicitly storing that level
doesn't add new assumptions.

> If comparing gfn_direct_bits to gfn_direct_bits doesn't make sense, then
> let's just drop the KVM_BUG_ON().

Why?  Defense in depth is often useful.