Hi, > Either mlock account (because it's mlocked defacto), and get_user_pages > won't do that for you. > > Or you write the full-blown userptr implementation, including mmu_notifier > support (see i915 or amdgpu), but that also requires Christian Königs > latest ->invalidate_mapping RFC for dma-buf (since atm exporting userptr > buffers is a no-go). I guess I'll look at mlock accounting for starters then. Easier for now, and leaves the door open to switch to userptr later as this should be transparent to userspace. > > Known issue: Driver API isn't complete yet. Need add some flags, for > > example to support read-only buffers. > > dma-buf has no concept of read-only. I don't think we can even enforce > that (not many iommus can enforce this iirc), so pretty much need to > require r/w memory. Ah, ok. Just saw the 'write' arg for get_user_pages_fast and figured we might support that, but if iommus can't handle that anyway it's pointless indeed. > > Cc: David Airlie <airlied@xxxxxxxx> > > Cc: Tomeu Vizoso <tomeu.vizoso@xxxxxxxxxxxxx> > > Signed-off-by: Gerd Hoffmann <kraxel@xxxxxxxxxx> > > btw there's also the hyperdmabuf stuff from the xen folks, but imo their > solution of forwarding the entire dma-buf api is over the top. This here > looks _much_ better, pls cc all the hyperdmabuf people on your next > version. Fun fact: googling for "hyperdmabuf" found me your mail and nothing else :-o (Trying "hyper dmabuf" instead worked better then). Yes, will cc them on the next version. Not sure it'll help much on xen though due to the memory management being very different. Basically xen owns the memory, not the kernel of the control domain (dom0), so creating dmabufs for guest memory chunks isn't that simple ... Also it's not clear whenever they really need guest -> guest exports or guest -> dom0 exports. > Overall I like the idea, but too lazy to review. Cool. General comments on the idea was all I was looking for for the moment. Spare yor review cycles for the next version ;) > Oh, some kselftests for this stuff would be lovely. I'll look into it. thanks, Gerd _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
