On Sun, May 11, 2025 at 7:18 PM Yan Zhao <yan.y.zhao@xxxxxxxxx> wrote: > ... > > > > I might be wrongly throwing out some terminologies here then. > > VM_PFNMAP flag can be set for memory backed by folios/page structs. > > udmabuf seems to be working with pinned "folios" in the backend. > > > > The goal is to get to a stage where guest_memfd is backed by pfn > > ranges unmanaged by kernel that guest_memfd owns and distributes to > > userspace, KVM, IOMMU subject to shareability attributes. if the > OK. So from point of the reset part of kernel, those pfns are not regarded as > memory. > > > shareability changes, the users will get notified and will have to > > invalidate their mappings. guest_memfd will allow mmaping such ranges > > with VM_PFNMAP flag set by default in the VMAs to indicate the need of > > special handling/lack of page structs. > My concern is a failable invalidation notifer may not be ideal. > Instead of relying on ref counts (or other mechanisms) to determine whether to > start shareabilitiy changes, with a failable invalidation notifier, some users > may fail the invalidation and the shareability change, even after other users > have successfully unmapped a range. Even if one user fails to invalidate its mappings, I don't see a reason to go ahead with shareability change. Shareability should not change unless all existing users let go of their soon-to-be-invalid view of memory. > > Auditing whether multiple users of shared memory correctly perform unmapping is > harder than auditing reference counts. > > > private memory backed by page structs and use a special "filemap" to > > map file offsets to these private memory ranges. This step will also > > need similar contract with users - > > 1) memory is pinned by guest_memfd > > 2) users will get invalidation notifiers on shareability changes > > > > I am sure there is a lot of work here and many quirks to be addressed, > > let's discuss this more with better context around. A few related RFC > > series are planned to be posted in the near future. > Ok. Thanks for your time and discussions :) > ...
