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 --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
