All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	"Song, Jike" <jike.song@intel.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"igvt-g@ml01.01.org" <igvt-g@ml01.01.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"White, Michael L" <michael.l.white@intel.com>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	"Li, Susie" <susie.li@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
	"Reddy, Raghuveer" <raghuveer.reddy@intel.com>,
	"Zhu, Libo" <libo.zhu@intel.com>,
	"Zhou, Chao" <chao.zhou@intel.com>,
	"Wang, Hongbo" <hongbo.wang@intel.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
Date: Fri, 04 Dec 2015 11:13:32 +0100	[thread overview]
Message-ID: <1449224012.18669.55.camel@redhat.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F72B52A@SHSMSX101.ccr.corp.intel.com>

  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


WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "igvt-g@ml01.01.org" <igvt-g@ml01.01.org>,
	"Song, Jike" <jike.song@intel.com>,
	"Reddy, Raghuveer" <raghuveer.reddy@intel.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"White, Michael L" <michael.l.white@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Li, Susie" <susie.li@intel.com>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	"Zhou, Chao" <chao.zhou@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Zhu, Libo" <libo.zhu@intel.com>,
	"Wang, Hongbo" <hongbo.wang@intel.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>
Subject: Re: [Qemu-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
Date: Fri, 04 Dec 2015 11:13:32 +0100	[thread overview]
Message-ID: <1449224012.18669.55.camel@redhat.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F72B52A@SHSMSX101.ccr.corp.intel.com>

  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

WARNING: multiple messages have this Message-ID (diff)
From: Gerd Hoffmann <kraxel@redhat.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "igvt-g@ml01.01.org" <igvt-g@ml01.01.org>,
	"Reddy, Raghuveer" <raghuveer.reddy@intel.com>,
	"White, Michael L" <michael.l.white@intel.com>,
	"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Li, Susie" <susie.li@intel.com>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Zhou, Chao" <chao.zhou@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Zhu, Libo" <libo.zhu@intel.com>,
	"Wang, Hongbo" <hongbo.wang@intel.com>
Subject: Re: [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
Date: Fri, 04 Dec 2015 11:13:32 +0100	[thread overview]
Message-ID: <1449224012.18669.55.camel@redhat.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F72B52A@SHSMSX101.ccr.corp.intel.com>

  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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-12-04 10:13 UTC|newest]

Thread overview: 176+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25  8:31 [Intel-gfx] [Announcement] Updates to XenGT - a Mediated Graphics Passthrough Solution from Intel Jike Song
2014-07-25  8:31 ` Jike Song
2014-07-29 10:09 ` [Xen-devel] [Intel-gfx] " Dario Faggioli
2014-07-29 10:09   ` Dario Faggioli
2014-07-30  9:39   ` Jike Song
2014-07-30  9:39   ` [Xen-devel] " Jike Song
2014-07-30  9:39     ` [Xen-devel] " Jike Song
2014-07-31 13:58     ` Dario Faggioli
2014-07-31 13:58     ` [Intel-gfx] " Dario Faggioli
2014-07-29 10:09 ` Dario Faggioli
2014-12-04  2:45 ` [Intel-gfx] [Announcement] 2014-Q3 release of " Jike Song
2014-12-04  2:45 ` Jike Song
2014-12-04  2:45   ` Jike Song
2014-12-04 10:20   ` [Intel-gfx] " Fabio Fantoni
2014-12-04 10:20   ` [Xen-devel] " Fabio Fantoni
2014-12-04 10:26     ` Tian, Kevin
2015-01-09  8:51   ` [Intel-gfx] [Announcement] 2015-Q1 " Jike Song
2015-01-09  8:51     ` Jike Song
2015-01-12  3:04     ` [Intel-gfx] [Announcement] 2014-Q4 " Jike Song
2015-01-12  3:04     ` Jike Song
2015-01-12  3:04       ` Jike Song
2015-04-10 13:23     ` [Intel-gfx] [Announcement] 2015-Q1 " Jike Song
2015-04-10 13:23     ` Jike Song
2015-04-10 13:23       ` Jike Song
2015-07-07  2:49       ` [Intel-gfx] [Announcement] 2015-Q2 " Jike Song
2015-07-07  2:49       ` Jike Song
2015-07-07  2:49         ` Jike Song
2015-10-27  9:25         ` [Intel-gfx] [Announcement] 2015-Q3 " Jike Song
2015-10-27  9:25           ` Jike Song
2015-11-18 18:12           ` [Intel-gfx] " Alex Williamson
2015-11-18 18:12             ` Alex Williamson
2015-11-18 18:12             ` [Qemu-devel] [Intel-gfx] " Alex Williamson
2015-11-19  4:06             ` Tian, Kevin
2015-11-19  4:06               ` Tian, Kevin
2015-11-19  4:06               ` [Qemu-devel] [Intel-gfx] " Tian, Kevin
2015-11-19  7:22               ` Jike Song
2015-11-19  7:22               ` Jike Song
2015-11-19  7:22                 ` Jike Song
2015-11-19  7:22                 ` [Qemu-devel] [Intel-gfx] " Jike Song
2015-11-19 15:32                 ` Stefano Stabellini
2015-11-19 15:32                 ` Stefano Stabellini
2015-11-19 15:32                   ` Stefano Stabellini
2015-11-19 15:32                   ` [Qemu-devel] " Stefano Stabellini
2015-11-19 15:49                   ` Paolo Bonzini
2015-11-19 15:49                     ` Paolo Bonzini
2015-11-19 15:49                     ` [Qemu-devel] [Intel-gfx] " Paolo Bonzini
2015-11-19 16:12                     ` Stefano Stabellini
2015-11-19 16:12                     ` Stefano Stabellini
2015-11-19 16:12                       ` [Qemu-devel] " Stefano Stabellini
2015-11-19 15:49                   ` Paolo Bonzini
2015-11-19 15:52                   ` Alex Williamson
2015-11-19 15:52                     ` Alex Williamson
2015-11-19 15:52                     ` [Qemu-devel] [Intel-gfx] " Alex Williamson
2015-11-20  2:58                     ` Jike Song
2015-11-20  2:58                       ` Jike Song
2015-11-20  2:58                       ` [Qemu-devel] [Intel-gfx] " Jike Song
2015-11-20  4:22                       ` Alex Williamson
2015-11-20  4:22                       ` Alex Williamson
2015-11-20  4:22                         ` Alex Williamson
2015-11-20  4:22                         ` [Qemu-devel] [Intel-gfx] " Alex Williamson
2015-11-20  5:51                         ` Jike Song
2015-11-20  5:51                           ` Jike Song
2015-11-20  5:51                           ` [Qemu-devel] [Intel-gfx] " Jike Song
2015-11-20  6:01                           ` Tian, Kevin
2015-11-20  6:01                             ` Tian, Kevin
2015-11-20  6:01                             ` [Qemu-devel] [Intel-gfx] " Tian, Kevin
2015-11-20  6:01                           ` Tian, Kevin
2015-11-20 16:40                           ` Alex Williamson
2015-11-20 16:40                             ` Alex Williamson
2015-11-20 16:40                             ` [Qemu-devel] [Intel-gfx] " Alex Williamson
2015-11-23  4:52                             ` Jike Song
2015-11-23  4:52                               ` Jike Song
2015-11-23  4:52                             ` Jike Song
2015-11-20 16:40                           ` Alex Williamson
2015-11-20  5:51                         ` Jike Song
2015-11-20  2:58                     ` Jike Song
2015-11-19 15:52                   ` Alex Williamson
2015-11-19  8:40               ` Gerd Hoffmann
2015-11-19  8:40               ` Gerd Hoffmann
2015-11-19  8:40                 ` Gerd Hoffmann
2015-11-19  8:40                 ` [Qemu-devel] [Intel-gfx] " Gerd Hoffmann
2015-11-19 11:09                 ` Paolo Bonzini
2015-11-19 11:09                   ` [Qemu-devel] " Paolo Bonzini
2015-11-20  2:46                   ` Jike Song
2015-11-20  2:46                   ` Jike Song
2015-11-20  2:46                     ` Jike Song
2015-11-20  2:46                     ` [Qemu-devel] [Intel-gfx] " Jike Song
2015-11-19 11:09                 ` Paolo Bonzini
2015-11-20  6:12                 ` Tian, Kevin
2015-11-20  6:12                   ` Tian, Kevin
2015-11-20  6:12                   ` [Qemu-devel] " Tian, Kevin
2015-11-20  8:26                   ` Gerd Hoffmann
2015-11-20  8:26                   ` Gerd Hoffmann
2015-11-20  8:26                     ` Gerd Hoffmann
2015-11-20  8:26                     ` [Qemu-devel] [Intel-gfx] " Gerd Hoffmann
2015-11-20  8:36                     ` Tian, Kevin
2015-11-20  8:36                     ` Tian, Kevin
2015-11-20  8:36                       ` Tian, Kevin
2015-11-20  8:36                       ` [Qemu-devel] [Intel-gfx] " Tian, Kevin
2015-11-20  8:46                       ` Zhiyuan Lv
2015-11-20  8:46                       ` Zhiyuan Lv
2015-11-20  8:46                         ` Zhiyuan Lv
2015-11-20  8:46                         ` [Qemu-devel] [Intel-gfx] " Zhiyuan Lv
2015-12-03  6:57                     ` Tian, Kevin
2015-12-03  6:57                       ` Tian, Kevin
2015-12-03  6:57                       ` [Qemu-devel] [Intel-gfx] " Tian, Kevin
2015-12-04 10:13                       ` Gerd Hoffmann [this message]
2015-12-04 10:13                         ` Gerd Hoffmann
2015-12-04 10:13                         ` [Qemu-devel] [Intel-gfx] " Gerd Hoffmann
2015-12-04 10:13                       ` Gerd Hoffmann
2015-12-03  6:57                     ` Tian, Kevin
2015-11-20  6:12                 ` Tian, Kevin
2015-11-19 20:02               ` Alex Williamson
2015-11-19 20:02                 ` Alex Williamson
2015-11-19 20:02                 ` [Qemu-devel] [Intel-gfx] " Alex Williamson
2015-11-20  7:09                 ` Tian, Kevin
2015-11-20  7:09                 ` Tian, Kevin
2015-11-20  7:09                   ` Tian, Kevin
2015-11-20  7:09                   ` [Qemu-devel] [Intel-gfx] " Tian, Kevin
2015-11-20 17:03                   ` Alex Williamson
2015-11-20 17:03                   ` Alex Williamson
2015-11-20 17:03                     ` Alex Williamson
2015-11-20 17:03                     ` [Qemu-devel] [Intel-gfx] " Alex Williamson
2015-11-20  8:10                 ` Tian, Kevin
2015-11-20  8:10                 ` Tian, Kevin
2015-11-20  8:10                   ` Tian, Kevin
2015-11-20  8:10                   ` [Qemu-devel] [Intel-gfx] " Tian, Kevin
2015-11-20 17:25                   ` Alex Williamson
2015-11-20 17:25                   ` Alex Williamson
2015-11-20 17:25                     ` Alex Williamson
2015-11-20 17:25                     ` [Qemu-devel] [Intel-gfx] " Alex Williamson
2015-11-23  5:05                     ` Jike Song
2015-11-23  5:05                     ` Jike Song
2015-11-23  5:05                       ` Jike Song
2015-11-23  5:05                       ` [Qemu-devel] [Intel-gfx] " Jike Song
2015-11-24 11:19                 ` Daniel Vetter
2015-11-24 11:19                   ` Daniel Vetter
2015-11-24 11:19                   ` [Qemu-devel] [Intel-gfx] " Daniel Vetter
2015-11-24 11:49                   ` Chris Wilson
2015-11-24 11:49                   ` Chris Wilson
2015-11-24 11:49                     ` Chris Wilson
2015-11-24 11:49                     ` [Qemu-devel] [Intel-gfx] " Chris Wilson
2015-11-24 12:38                   ` Gerd Hoffmann
2015-11-24 12:38                   ` Gerd Hoffmann
2015-11-24 12:38                     ` Gerd Hoffmann
2015-11-24 12:38                     ` [Qemu-devel] [Intel-gfx] " Gerd Hoffmann
2015-11-24 13:31                     ` Daniel Vetter
2015-11-24 13:31                       ` Daniel Vetter
2015-11-24 13:31                       ` [Qemu-devel] [Intel-gfx] " Daniel Vetter
2015-11-24 14:12                       ` Gerd Hoffmann
2015-11-24 14:12                       ` Gerd Hoffmann
2015-11-24 14:12                         ` Gerd Hoffmann
2015-11-24 14:12                         ` [Qemu-devel] [Intel-gfx] " Gerd Hoffmann
2015-11-24 14:19                         ` Daniel Vetter
2015-11-24 14:19                         ` Daniel Vetter
2015-11-24 14:19                           ` Daniel Vetter
2015-11-24 14:19                           ` [Qemu-devel] [Intel-gfx] " Daniel Vetter
2015-11-24 13:31                     ` Daniel Vetter
2015-11-24 11:19                 ` Daniel Vetter
2015-11-19 20:02               ` Alex Williamson
2015-11-19  4:06             ` Tian, Kevin
2015-11-18 18:12           ` Alex Williamson
2016-01-27  6:21           ` [Intel-gfx] [Announcement] 2015-Q4 " Jike Song
2016-01-27  6:21           ` Jike Song
2016-01-27  6:21             ` Jike Song
2016-04-28  5:29             ` [Intel-gfx] [Announcement] 2016-Q1 " Jike Song
2016-04-28  5:29               ` Jike Song
2016-07-22  5:42               ` [Intel-gfx] [Announcement] 2016-Q2 " Jike Song
2016-07-22  5:42               ` Jike Song
2016-07-22  5:42                 ` Jike Song
2016-11-06 14:59                 ` [Intel-gfx] [Announcement] 2016-Q3 " Jike Song
2016-11-06 14:59                 ` Jike Song
2016-11-06 14:59                   ` Jike Song
2016-04-28  5:29             ` [Intel-gfx] [Announcement] 2016-Q1 " Jike Song
2015-10-27  9:25         ` [Intel-gfx] [Announcement] 2015-Q3 " Jike Song
2015-01-09  8:51   ` [Intel-gfx] [Announcement] 2015-Q1 " Jike Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1449224012.18669.55.camel@redhat.com \
    --to=kraxel@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=chao.zhou@intel.com \
    --cc=david.j.cowperthwaite@intel.com \
    --cc=eddie.dong@intel.com \
    --cc=hongbo.wang@intel.com \
    --cc=igvt-g@ml01.01.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jike.song@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=libo.zhu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.l.white@intel.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=raghuveer.reddy@intel.com \
    --cc=susie.li@intel.com \
    --cc=xen-devel@lists.xen.org \
    --cc=zhiyuan.lv@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.