[RFC v3 2/3] virtio: Introduce Vdmabuf driver
Gerd Hoffmann
kraxel at redhat.com
Mon Feb 8 07:57:48 UTC 2021
Hi,
> > +/* extract pages referenced by sgt */
> > +static struct page **extr_pgs(struct sg_table *sgt, int *nents, int *last_len)
>
> Nack, this doesn't work on dma-buf. And it'll blow up at runtime when you
> enable the very recently merged CONFIG_DMABUF_DEBUG (would be good to test
> with that, just to make sure).
> Aside from this, for virtio/kvm use-cases we've already merged the udmabuf
> driver. Does this not work for your usecase?
udmabuf can be used on the host side to make a collection of guest pages
available as host dmabuf. It's part of the puzzle, but not a complete
solution.
As I understand it the intended workflow is this:
(1) guest gpu driver exports some object as dma-buf
(2) dma-buf is imported into this new driver.
(3) driver sends the pages to the host.
(4) hypervisor uses udmabuf to create a host dma-buf.
(5) host dma-buf is passed on.
And step (3) is the problematic one as this will not
work in case the dma-buf doesn't live in guest ram but
in -- for example -- gpu device memory.
Reversing the driver roles in the guest (virtio driver
allocates pages and exports the dma-buf to the guest
gpu driver) should work fine.
Which btw is something you can do today with virtio-gpu.
Maybe it makes sense to have the option to run virtio-gpu
in render-only mode for that use case.
take care,
Gerd
More information about the dri-devel
mailing list