Re: [PATCH 1/2] x86/virt/tdx: Use PFN directly for mapping guest private memory

Sean Christopherson
2026-04-02T22:11:58Z

On Thu, Apr 02, 2026, Dave Hansen wrote:
> On 4/2/26 13:47, Sean Christopherson wrote:
> > On Thu, Mar 19, 2026, Dave Hansen wrote:
> >> On 3/18/26 17:57, Yan Zhao wrote:
> >>> Remove the completely unnecessary assumption that memory mapped into a TDX
> >>> guest is backed by refcounted struct page memory. From KVM's point of view,
> >>> TDH_MEM_PAGE_ADD and TDH_MEM_PAGE_AUG are glorified writes to PTEs, so they
> >>> have no business placing requirements on how KVM and guest_memfd manage
> >>> memory.
> >>
> >> I think this goes a bit too far.
> >>
> >> It's one thing to say that it's more convenient for KVM to stick with
> >> pfns because it's what KVM uses now. Or, that the goals of using 'struct
> >> page' can be accomplished other ways. It's quite another to say what
> >> other bits of the codebase have "business" doing.
> >>
> >> Sean, can we tone this down a _bit_ to help guide folks in the future?
> >
> > I strongly disagree on this one.
>
> I think I understand the motivation now. All I'm saying is that instead
> of something like:
>
> Remove the completely unnecessary assumption that memory mapped
> into a TDX guest is backed by refcounted struct page memory.
>
> I'd rather see something along the lines of
>
> KVM's MMUs work with PFNs. This is very much an intentional
> design choice. It ensures that the KVM MMUs remains flexible
> and are not too tied to the regular CPU MMUs and the kernel code
> around them.
>
> Using 'struct page' for TDX memory is not a good fit anywhere
> near the KVM MMU code.
>
> Would you disagree strongly with that kind of rewording?

Not at all, works for me.