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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
