[lkml]   [2018]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RfC PATCH] Add udmabuf misc device
Pulling this out of the shadows again.

We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff
from Matt and Dongwong.

At least from the intel side there seems to be the idea to just have 1
special device that can handle cross-gues/host sharing for all kinds
of hypervisors, so I guess you all need to work together :-)

Or we throw out the idea that hyper dmabuf will be cross-hypervisor
(not sure how useful/reasonable that is, someone please convince me
one way or the other).

Cheers, Daniel

On Wed, Mar 14, 2018 at 9:03 AM, Gerd Hoffmann <> wrote:
> 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 <>
>> > Cc: Tomeu Vizoso <>
>> > Signed-off-by: Gerd Hoffmann <>
>> 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

Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -

 \ /
  Last update: 2018-04-05 22:32    [W:0.122 / U:0.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site