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

[Yan Zhao]

On Thu, May 07, 2026 at 03:49:09PM +0800, Xiaoyao Li wrote:
> On 4/30/2026 9:49 AM, Yan Zhao wrote:
> > From: Sean Christopherson <seanjc@xxxxxxxxxx>
> > 
> > Remove struct page assumptions/constraints in the SEAMCALL wrapper APIs for
> > mapping guest private memory and have them take PFN directly.
> > 
> > Having core TDX make assumptions that guest private memory must be backed
> > by struct page (and/or folio) will create subtle dependencies on how
> > KVM/guest_memfd allocates/manages memory (e.g., whether it uses memory
> > allocated from core MM, if the memory is refcounted, or if the folio is
> > split) that are easily avoided. [1].
> > 
> > KVM's MMUs work with PFNs. This is very much an intentional design choice.
> > It ensures that the KVM MMUs remain flexible and are not too tied to the
> > regular CPU MMUs and the kernel code around them. Using 'struct page' for
> > TDX guest memory is not a good fit anywhere near the KVM MMU code [2].
> > 
> > Use "kvm_pfn_t pfn" for type safety. Using this KVM type is appropriate
> > since APIs tdh_mem_page_add() and tdh_mem_page_aug() are exported to KVM
> > only.
> > 
> > [ Yan: Replace "u64 pfn" with "kvm_pfn_t pfn" ]
> > 
> > Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> > Signed-off-by: Yan Zhao <yan.y.zhao@xxxxxxxxx>
> > Link: https://lore.kernel.org/all/aWgyhmTJphGQqO0Y@xxxxxxxxxx [1]
> > Link: https://lore.kernel.org/all/ac7V0g2q2hN3dU5u@xxxxxxxxxx [2]
> 
> Reviewed-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>
Thanks!

> > +static void tdx_clflush_pfn(kvm_pfn_t pfn)
> > +{
> > +	clflush_cache_range(__va(PFN_PHYS(pfn)), PAGE_SIZE);
> 
> If the pfn is not in the kernel direct map, we will get #PF, right?
Right.

There's no simple interface like pfn_range_is_mapped() that tells whether a PFN
has direct map or not if removing direct map is supported.

So, as PFNs not in the kernel direct map are unexpected for TDX, this series
leaves #PF, which is obvious enough for debugging.

> There is on-going attempt to remove the direct map for guest_memfd. The good
> news is TDX is excluded. [1]
We can see if any code refinement is necessary if TDX is included in the future.

 
> [1] https://lore.kernel.org/all/20260410151746.61150-9-kalyazin@xxxxxxxxxx/