Re: [PATCH v2] KVM: x86/mmu: Expose number of shadow MMU shadow pages as a stat

[Yosry Ahmed]

On Mon, Jun 15, 2026 at 5:20 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
>
> On Mon, Jun 15, 2026, Yosry Ahmed wrote:
> > On Mon, Jun 15, 2026 at 4:46 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote:
> > > > I guess for most cases, mmu_shadow_pages will represent either the MMU
> > > > pages used to shadow the VM's x86 page tables (with TDP off) or nested
> > > > TDP MMU pages (with TDP on and nested used) -- but I do remember some
> > > > interesting case about direct mappings in the shadow MMU or sth?
> > >
> > > Yes, there can direct shadow pages in an indirect mmu (guest is using a page size
> > > that is larger than the host, in which case there are no gPTEs to shadow and thus
> > > the gva=>gpa / l2_gpa=>l1_gpa translations in KVM's shadow pages are "direct").
> >
> > I never understood why these are "direct" tho. Sure, they do not
> > directly correspond gPTEs, but they still are shadowing guest
> > mappings.
>
> No, the *parent* is shadowing a gPTE, the child is not.  Overall, KVM is shadowing
> a mapping, but individual shadow pages are shadowing a specific gPTE in a specific
> context, not a full mapping.
>
> > IOW, if the guest has a PMD mapping and KVM has some PTE mappings, aren't
> > those PTE mappings still shadowing the PMD mapping,
>
> Nope, as above, there is an indirect shadow page with a base GFN that corresponds
> to the guest PMD entry, i.e. that is shadowing the huge gPMD.  And so if that
> gPMD is modified, KVM needs to adjust that parent shadow page.
>
> But for the PG_LEVEL_4K shadow pages, i.e. the children, there is no corresponding
> page table, no gPTEs to shadow, no gfn that needs write-protection, no protection
> bits to account for, and no additional lookup to do when getting from the base GFN
> to the final GFN.
>
> See the use of sp->shadowed_translation, e.g. in kvm_mmu_page_get_gfn() and
> kvm_mmu_page_get_access(), and also commit 9ecc1c119b28 ("KVM: x86/mmu: Only
> allocate shadowed translation cache for sp->role.level <= KVM_MAX_HUGEPAGE_LEVEL"),
> which optimized KVM to avoid allocating unused metadata (KVM only ever needs to
> query the gfn and access protections for leaf SPTEs).

Yeah I guess the distinction makes sense from the shadow MMU
implementation perspective, what I was really getting at is that, to
your point, maybe it's best not to expose the direct/indirect
distinction to userspace (unless we already do elsewhere?). Seems like
the distinction (or rather the terminology) is implementation-specific
and can (in theory) change.

>
> > and still need to be sync'd in the same way they would if they were shadowing
> > PTEs?
>
> Ignoring for the moment that KVM never unsyncs PMD+ gPTEs, "yes", but only the
> parents.