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.
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
though.
While we're talking about this: what is your plan for virtio-gpu implementations for non-Linux guests/hosts?
cheers,
Gerd