On Mon, Jul 24, 2023 at 07:54:38AM +0000, Kasireddy, Vivek wrote: > > I'm not at all familiar with the udmabuf use case but that sounds > > brittle and effectively makes this notifier udmabuf specific right? > Oh, Qemu uses the udmabuf driver to provide Host Graphics components > (such as Spice, Gstreamer, UI, etc) zero-copy access to Guest created > buffers. In other words, from a core mm standpoint, udmabuf just > collects a bunch of pages (associated with buffers) scattered inside > the memfd (Guest ram backed by shmem or hugetlbfs) and wraps > them in a dmabuf fd. And, since we provide zero-copy access, we > use DMA fences to ensure that the components on the Host and > Guest do not access the buffer simultaneously.
So why do you need to track updates proactively like this? Trigger a move when the backing memory changes and re-acquire it with hmm_range_fault like everything else does. > And replace mmu_notifier_update_mapping(vma->vm_mm, address, pte_pfn(*ptep)) > in the current patch with > mmu_notifier_change_pte(vma->vm_mm, address, ptep, false)); It isn't very useful because nothing can do anything meaningful under the PTLs. Can't allocate memory for instance. Which makes me wonder what it is udmabuf plans to actually do here. JAson
