On Tue, Jul 8, 2025 at 4:16 PM Edgecombe, Rick P <rick.p.edgecombe@xxxxxxxxx> wrote: > > On Tue, 2025-07-08 at 15:06 -0700, Vishal Annapurve wrote: > > > > My vote would be to prefer using "hpa" and not rely on folio/page > > > > structs for guest_memfd allocated memory wherever possible. > > > > > > Is this because you want to enable struct page-less gmemfd in the future? > > > > Yes. That's the only reason. > > I don't think we should change just this field of this seamcall wrapper from the > current pattern for that reason. When this stuff comes along it will be just > about as easy to change it with the rest. Then in the meantime it doesn't look > asymmetric. > > In general, I (again) think that we should not focus on accommodating future > stuff unless there is an ABI touch point. This is to ultimately speed enabling > of the entire stack. > > It is definitely not to make it harder to implement TDX support for pfn based > gmem in the future. Rather to make it possible. As in, if nothing is upstream > because we are endlessly debating how it all fits together at once, then it > won't be possible to enhance it further. I agree and if we can't do without page struct for now that's fine. My response was just to favor pfn/hpa over "page struct" if possible, given that we have a choice here. Feel free to ignore if symmetry seems more important.
