On Thu, Oct 17, 2024 at 01:05:34PM -0400, Peter Xu wrote: > On Thu, Oct 17, 2024 at 01:47:13PM -0300, Jason Gunthorpe wrote: > > On Thu, Oct 17, 2024 at 10:58:29AM -0400, Peter Xu wrote: > > > > > My question was more torwards whether gmemfd could still expose the > > > possibility to be used in VA forms to other modules that may not support > > > fd+offsets yet. > > > > I keep hearing they don't want to support page pinning on a guestmemfd > > mapping, so VA based paths could not work. > > Do you remember the reasoning of it? Is it because CoCo still needs to > have a bounded time window to convert from shared back to private?
I think so > If so, maybe that's a non-issue for non-CoCo, where the VM object / > gmemfd object (when created) can have a flag marking that it's > always shared and can never be converted to private for any page > within. What is non-CoCo? Does it include the private/shared concept? > So how would VFIO's DMA work even with iommufd if pages cannot be pinned? > Is some form of bounce buffering required, then? We can do some kind of atomic replace during a private/shared exchange. In some HW cases the iommu table doesn't even need an update. It will be tricky stuff. Jason
