Re: [PATCH v2 2/4] x86/tdx: Use PFN directly for unmapping guest private memory
From: Sean Christopherson
Date: Thu Apr 30 2026 - 15:20:43 EST
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.