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? [0] https://lore.kernel.org/kvm/30d0cef5-82d5-4325-b149-0e99833b8785@xxxxxxxxx/
