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

[Xiaoyao Li]

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>

...
> +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?

There is on-going attempt to remove the direct map for guest_memfd. The 
good news is TDX is excluded. [1]

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