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

On Tue, Feb 19, 2019 at 10:52 PM Gerd Hoffmann <kraxel@redhat.com> wrote:

> 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.

This plus new transport makes me wonder if we can have something like a transport/device pair
where the transport makes it easy to work directly off host memory pci bar,
and the device is virtio-gpu except really just buffers.
We'd really like to go for something like this.

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).

Got it, that sounds pretty interesting.
Non-linux systems obviously need something else for the job. The
guest/host implementation details don't affect the virtio-gpu specs

While we're talking about this: what is your plan for virtio-gpu implementations for non-Linux guests/hosts?

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