Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

[Gerd Hoffmann]

  Hi,

> btw some questions here:
> 
> for non-gl and gl rendering in Qemu, are they based on dma-buf already?

> once we can export guest framebuffer in dma-buf, is there additional work
> required or just straightforward to integrate with SPICE?

Right now we are busy integrating dma-buf support into spice, which will
be used for the gl rendering path, for virtio-gpu.

For intel-vgpu the wireup inside qemu will be slightly different:  We'll
get a dma-buf handle from the igd driver, whereas virtio-gpu renders
into a texture, then exports that texture as dma-buf.

But in both cases we'll go pass the dma-buf with the guest framebuffer
(and meta-data such as fourcc and size) to spice-server, which in turn
will pass on the dma-buf to spice-client for (local) display.  So we
have a common code path in spice for both virtio-gpu and intel-vgpu,
based on dma-bufs.  spice-server even doesn't need to know what kind of
graphics device the guest has, it'll go just process the dma-bufs.

longer-term we also plan to support video-encoding for a remote display.
Again based on dma-bufs, by sending them to the gpu video encoder.


The non-gl rendering path needs to be figured out.

With virtio-gpu we'll go simply turn off 3d support, so the guest will
fallback to do software rendering, we'll get a classic DisplaySurface
and the vnc server can work with that.

That isn't going to fly with intel-vgpu though, so we need something
else.  Import dma-buf, then glReadPixels into a DisplaySurface would
work.  But as mentioned before I'd prefer a code path which doesn't
require opengl support in qemu, and one option for that would be the
special vfio region.  I've written up a quick draft meanwhile:


diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
index 751b69f..91b928d 100644
--- a/include/uapi/linux/vfio.h
+++ b/include/uapi/linux/vfio.h
@@ -596,6 +596,28 @@ struct vfio_iommu_spapr_tce_remove {
 };
 #define VFIO_IOMMU_SPAPR_TCE_REMOVE    _IO(VFIO_TYPE, VFIO_BASE + 20)
 
+/* -------- Additional API for vGPU -------- */
+
+/*
+ * framebuffer meta data
+ * subregion located at the end of the framebuffer region
+ */
+struct vfio_framebuffer {
+       __u32 argsz;
+
+       /* out */
+       __u32 format;    /* drm fourcc */
+       __u32 offset;    /* relative to region start */
+       __u32 width;     /* in pixels */
+       __u32 height;    /* in pixels */
+       __u32 stride;    /* in bytes  */
+
+       /* in+out */
+#define VFIO_FB_STATE_REQUEST_UPDATE   1  /* userspace requests update
*/
+#define VFIO_FB_STATE_UPDATE_COMPLETE  2  /* kernel signals completion
*/
+       __u32 state;     /* VFIO_FB_STATE_ */
+};
+
 /* ***************************************************************** */
 
 #endif /* _UAPIVFIO_H */

cheers,
  Gerd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/