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

[Sean Christopherson <seanjc@google.com>]

On Thu, Apr 30, 2026, Rick P Edgecombe wrote:
> On Thu, 2026-04-30 at 11:17 -0700, Ackerley Tng wrote:
> > >   {
> > >   	const void *zero_page = (const void *)page_address(ZERO_PAGE(0));
> > >   	unsigned long phys, end;
> > > @@ -729,6 +729,7 @@ static void tdx_quirk_reset_paddr(unsigned long base, unsigned long size)
> > >   	 */
> > >   	mb();
> > >   }
> > > +EXPORT_SYMBOL_FOR_KVM(tdx_quirk_reset_paddr);
> > > 
> > >   void tdx_quirk_reset_page(struct page *page)
> > >   {
> > > @@ -1920,17 +1921,17 @@ u64 tdh_phymem_page_wbinvd_tdr(struct tdx_td *td)
> > >   {
> > >   	struct tdx_module_args args = {};
> > > 
> > > -	args.rcx = mk_keyed_paddr(tdx_global_keyid, td->tdr_page);
> > > +	args.rcx = mk_keyed_paddr(tdx_global_keyid, page_to_pfn(td->tdr_page));
> > 
> > Should mk_keyed_paddr() be updated to have a return type of phys_addr_t?
> > I guess in this case since mk_keyed_paddr() is pretty much an internal
> > function, returning u64 also makes sense to indicate that it should only
> > be used to set 64 bit registers.
> 
> Yea, this is used to construct u64 inputs for seamcall args. So I think it
> should keep returning u64s.

+1.  IMO, we should treat the TDX-Module as an extension of hardware and pass in
u64s where the spec says it takes a 64-bit value.