Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> > > > 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).
> [Kasireddy, Vivek] Although, I have not tested it yet but it looks like this will
> throw a wrench in our solution as we use sg_next to iterate over all the struct page *
> and get their PFNs. I wonder if there is any other clean way to get the PFNs of all 
> the pages associated with a dmabuf.

Well, there is no guarantee that dma-buf backing storage actually has
struct page ...

> [Kasireddy, Vivek] To exclude such cases, would it not be OK to limit the scope 
> of this solution (Vdmabuf) to make it clear that the dma-buf has to live in Guest RAM?
> Or, are there any ways to pin the dma-buf pages in Guest RAM to make this
> solution work?

At that point it becomes (i915) driver-specific.  If you go that route
it doesn't look that useful to use dma-bufs in the first place ...

> IIUC, Virtio GPU is used to present a virtual GPU to the Guest and all the rendering 
> commands are captured and forwarded to the Host GPU via Virtio.

You don't have to use the rendering pipeline.  You can let the i915 gpu
render into a dma-buf shared with virtio-gpu, then use virtio-gpu only for
buffer sharing with the host.

take care,
  Gerd