On Tue, Jul 8, 2025 at 6:56 AM Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx> wrote: > > On Tue, 2025-07-08 at 16:48 +0800, Yan Zhao wrote: > > On Thu, Apr 24, 2025 at 11:04:28AM +0800, Yan Zhao wrote: > > > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c > > > index f5e2a937c1e7..a66d501b5677 100644 > > > --- a/arch/x86/virt/vmx/tdx/tdx.c > > > +++ b/arch/x86/virt/vmx/tdx/tdx.c > > > @@ -1595,9 +1595,18 @@ u64 tdh_mem_page_aug(struct tdx_td *td, u64 gpa, int level, struct page *page, u > > According to the discussion in DPAMT [*], > > "hpa here points to a 2M region that pamt_pages covers. We don't have > > struct page that represents it. Passing 4k struct page would be > > misleading IMO." > > > > Should we update tdh_mem_page_aug() accordingly to use hpa? > > Or use struct folio instead? > > > > [*] https://lore.kernel.org/all/3coaqkcfp7xtpvh2x4kph55qlopupknm7dmzqox6fakzaedhem@a2oysbvbshpm/ > > The original seamcall wrapper patches used "u64 hpa", etc everywhere. The > feedback was that it was too error prone to not have types. We looked at using > kvm types (hpa_t, etc), but the type checking was still just surface level [0]. > > So the goal is to reduce errors and improve code readability. We can consider > breaking symmetry if it is better that way. In this case though, why not use > struct folio? My vote would be to prefer using "hpa" and not rely on folio/page structs for guest_memfd allocated memory wherever possible. > > [0] https://lore.kernel.org/kvm/30d0cef5-82d5-4325-b149-0e99833b8785@xxxxxxxxx/
