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