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

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 4/30/2026 9:49 AM, Yan Zhao wrote:
> From: Sean Christopherson<seanjc@google.com>
> 
> Remove struct page assumptions/constraints in APIs for unmapping guest
> private memory and have them take physical address 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 tightly 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].
> 
> Therefore, for unmapping guest private memory: export
> tdx_quirk_reset_paddr() for direct KVM invocation, and convert the SEAMCALL
> wrapper API tdh_phymem_page_wbinvd_hkid() to take PFN as input (thus
> updating mk_keyed_paddr() and tdh_phymem_page_wbinvd_tdr()).
> 
> Intentionally have KVM pass PAGE_SIZE (rather than KVM_HPAGE_SIZE(level))
> to tdx_quirk_reset_paddr() in tdx_sept_remove_private_spte() to avoid
> mixing in huge page changes. The KVM_BUG_ON() check for !PG_LEVEL_4K in
> tdx_sept_remove_private_spte() justifies using PAGE_SIZE.
> 
> Do not convert tdx_reclaim_page() to use PFN as input since it currently
> does not remove guest private memory.
> 
> Use "kvm_pfn_t pfn" for type safety. Using this KVM type is appropriate
> since APIs tdh_phymem_page_wbinvd_hkid() and tdx_quirk_reset_paddr() are
> exported to KVM only.
> 
> [Yan: Use kvm_pfn_t,exclude tdx_reclaim_page(),use tdx_quirk_reset_paddr()]
> 
> Signed-off-by: Sean Christopherson<seanjc@google.com>
> Signed-off-by: Yan Zhao<yan.y.zhao@intel.com>
> Link:https://lore.kernel.org/all/aWgyhmTJphGQqO0Y@google.com [1]
> Link:https://lore.kernel.org/all/ac7V0g2q2hN3dU5u@google.com [2]

Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>