OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] Memory sharing device


  Hi,

> However, dma-buf seems to require either a Linux kernel or a Linux host.

Sure.  They allow passing buffers from one linux driver to another
without copying the data.

> Dma-bufs aren't also 1:1 with Vulkan host visible memory pointers,
> or v4l2 codec buffers, or ffmpeg codec buffers, etc.

Some v4l2 drivers have dma-buf support, so you can pass buffers from
v4l2 to (for example) gpu drivers that way.

> The proposed device would be able to expose memory for direct access in a
> way that
> does not couple to dma-buf which is highly desirable for our use case.
> Using the ping/event messages, even win32 handles and general opaque fds
> can be passed from host to guest and back.
> 
> You can think of the proposed device as a 'virtio-dmabuf' that
> tries to expose shareable memory in a way that disregards implementation
> details of
> guest and host kernels.

That would probably look alot like virtio-gpu with only the resource
handling.  virtio-gpu fundamentally are just buffers.

Also virtio-dmabuf would be a pretty bad name.  dma-bufs are not a
virtio concept, they are a linux concept.  They can be used by linux
guests, to pass buffers from/to virtio-gpu (note: I'm still busy adding
driver support for that).  They can be used by linux hosts, to pass
buffers (with udmabuf help) from qemu to other processes/devices
(details are still to be hashed out).

Non-linux systems obviously need something else for the job.  The
guest/host implementation details don't affect the virtio-gpu specs
though.

cheers,
  Gerd



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]