From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel Date: Fri, 04 Dec 2015 11:13:32 +0100 Message-ID: <1449224012.18669.55.camel@redhat.com> References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com> <54AF967B.3060503@intel.com> <5527CEC4.9080700@intel.com> <559B3E38.1080707@intel.com> <562F4311.9@intel.com> <1447870341.4697.92.camel@redhat.com> <1447922452.25140.39.camel@redhat.com> <1448007960.6904.22.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTPS id CF3B76E437 for ; Fri, 4 Dec 2015 02:13:35 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: "Tian, Kevin" Cc: "igvt-g@ml01.01.org" , "Reddy, Raghuveer" , "White, Michael L" , "Cowperthwaite, David J" , "intel-gfx@lists.freedesktop.org" , "Li, Susie" , "Dong, Eddie" , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xen.org" , qemu-devel , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" List-Id: intel-gfx@lists.freedesktop.org ICBIaSwKCj4gYnR3IHNvbWUgcXVlc3Rpb25zIGhlcmU6Cj4gCj4gZm9yIG5vbi1nbCBhbmQgZ2wg cmVuZGVyaW5nIGluIFFlbXUsIGFyZSB0aGV5IGJhc2VkIG9uIGRtYS1idWYgYWxyZWFkeT8KCj4g b25jZSB3ZSBjYW4gZXhwb3J0IGd1ZXN0IGZyYW1lYnVmZmVyIGluIGRtYS1idWYsIGlzIHRoZXJl IGFkZGl0aW9uYWwgd29yawo+IHJlcXVpcmVkIG9yIGp1c3Qgc3RyYWlnaHRmb3J3YXJkIHRvIGlu dGVncmF0ZSB3aXRoIFNQSUNFPwoKUmlnaHQgbm93IHdlIGFyZSBidXN5IGludGVncmF0aW5nIGRt YS1idWYgc3VwcG9ydCBpbnRvIHNwaWNlLCB3aGljaCB3aWxsCmJlIHVzZWQgZm9yIHRoZSBnbCBy ZW5kZXJpbmcgcGF0aCwgZm9yIHZpcnRpby1ncHUuCgpGb3IgaW50ZWwtdmdwdSB0aGUgd2lyZXVw IGluc2lkZSBxZW11IHdpbGwgYmUgc2xpZ2h0bHkgZGlmZmVyZW50OiAgV2UnbGwKZ2V0IGEgZG1h LWJ1ZiBoYW5kbGUgZnJvbSB0aGUgaWdkIGRyaXZlciwgd2hlcmVhcyB2aXJ0aW8tZ3B1IHJlbmRl cnMKaW50byBhIHRleHR1cmUsIHRoZW4gZXhwb3J0cyB0aGF0IHRleHR1cmUgYXMgZG1hLWJ1Zi4K CkJ1dCBpbiBib3RoIGNhc2VzIHdlJ2xsIGdvIHBhc3MgdGhlIGRtYS1idWYgd2l0aCB0aGUgZ3Vl c3QgZnJhbWVidWZmZXIKKGFuZCBtZXRhLWRhdGEgc3VjaCBhcyBmb3VyY2MgYW5kIHNpemUpIHRv IHNwaWNlLXNlcnZlciwgd2hpY2ggaW4gdHVybgp3aWxsIHBhc3Mgb24gdGhlIGRtYS1idWYgdG8g c3BpY2UtY2xpZW50IGZvciAobG9jYWwpIGRpc3BsYXkuICBTbyB3ZQpoYXZlIGEgY29tbW9uIGNv ZGUgcGF0aCBpbiBzcGljZSBmb3IgYm90aCB2aXJ0aW8tZ3B1IGFuZCBpbnRlbC12Z3B1LApiYXNl ZCBvbiBkbWEtYnVmcy4gIHNwaWNlLXNlcnZlciBldmVuIGRvZXNuJ3QgbmVlZCB0byBrbm93IHdo YXQga2luZCBvZgpncmFwaGljcyBkZXZpY2UgdGhlIGd1ZXN0IGhhcywgaXQnbGwgZ28ganVzdCBw cm9jZXNzIHRoZSBkbWEtYnVmcy4KCmxvbmdlci10ZXJtIHdlIGFsc28gcGxhbiB0byBzdXBwb3J0 IHZpZGVvLWVuY29kaW5nIGZvciBhIHJlbW90ZSBkaXNwbGF5LgpBZ2FpbiBiYXNlZCBvbiBkbWEt YnVmcywgYnkgc2VuZGluZyB0aGVtIHRvIHRoZSBncHUgdmlkZW8gZW5jb2Rlci4KCgpUaGUgbm9u LWdsIHJlbmRlcmluZyBwYXRoIG5lZWRzIHRvIGJlIGZpZ3VyZWQgb3V0LgoKV2l0aCB2aXJ0aW8t Z3B1IHdlJ2xsIGdvIHNpbXBseSB0dXJuIG9mZiAzZCBzdXBwb3J0LCBzbyB0aGUgZ3Vlc3Qgd2ls bApmYWxsYmFjayB0byBkbyBzb2Z0d2FyZSByZW5kZXJpbmcsIHdlJ2xsIGdldCBhIGNsYXNzaWMg RGlzcGxheVN1cmZhY2UKYW5kIHRoZSB2bmMgc2VydmVyIGNhbiB3b3JrIHdpdGggdGhhdC4KClRo YXQgaXNuJ3QgZ29pbmcgdG8gZmx5IHdpdGggaW50ZWwtdmdwdSB0aG91Z2gsIHNvIHdlIG5lZWQg c29tZXRoaW5nCmVsc2UuICBJbXBvcnQgZG1hLWJ1ZiwgdGhlbiBnbFJlYWRQaXhlbHMgaW50byBh IERpc3BsYXlTdXJmYWNlIHdvdWxkCndvcmsuICBCdXQgYXMgbWVudGlvbmVkIGJlZm9yZSBJJ2Qg cHJlZmVyIGEgY29kZSBwYXRoIHdoaWNoIGRvZXNuJ3QKcmVxdWlyZSBvcGVuZ2wgc3VwcG9ydCBp biBxZW11LCBhbmQgb25lIG9wdGlvbiBmb3IgdGhhdCB3b3VsZCBiZSB0aGUKc3BlY2lhbCB2Zmlv IHJlZ2lvbi4gIEkndmUgd3JpdHRlbiB1cCBhIHF1aWNrIGRyYWZ0IG1lYW53aGlsZToKCgpkaWZm IC0tZ2l0IGEvaW5jbHVkZS91YXBpL2xpbnV4L3ZmaW8uaCBiL2luY2x1ZGUvdWFwaS9saW51eC92 ZmlvLmgKaW5kZXggNzUxYjY5Zi4uOTFiOTI4ZCAxMDA2NDQKLS0tIGEvaW5jbHVkZS91YXBpL2xp bnV4L3ZmaW8uaAorKysgYi9pbmNsdWRlL3VhcGkvbGludXgvdmZpby5oCkBAIC01OTYsNiArNTk2 LDI4IEBAIHN0cnVjdCB2ZmlvX2lvbW11X3NwYXByX3RjZV9yZW1vdmUgewogfTsKICNkZWZpbmUg VkZJT19JT01NVV9TUEFQUl9UQ0VfUkVNT1ZFICAgIF9JTyhWRklPX1RZUEUsIFZGSU9fQkFTRSAr IDIwKQogCisvKiAtLS0tLS0tLSBBZGRpdGlvbmFsIEFQSSBmb3IgdkdQVSAtLS0tLS0tLSAqLwor CisvKgorICogZnJhbWVidWZmZXIgbWV0YSBkYXRhCisgKiBzdWJyZWdpb24gbG9jYXRlZCBhdCB0 aGUgZW5kIG9mIHRoZSBmcmFtZWJ1ZmZlciByZWdpb24KKyAqLworc3RydWN0IHZmaW9fZnJhbWVi dWZmZXIgeworICAgICAgIF9fdTMyIGFyZ3N6OworCisgICAgICAgLyogb3V0ICovCisgICAgICAg X191MzIgZm9ybWF0OyAgICAvKiBkcm0gZm91cmNjICovCisgICAgICAgX191MzIgb2Zmc2V0OyAg ICAvKiByZWxhdGl2ZSB0byByZWdpb24gc3RhcnQgKi8KKyAgICAgICBfX3UzMiB3aWR0aDsgICAg IC8qIGluIHBpeGVscyAqLworICAgICAgIF9fdTMyIGhlaWdodDsgICAgLyogaW4gcGl4ZWxzICov CisgICAgICAgX191MzIgc3RyaWRlOyAgICAvKiBpbiBieXRlcyAgKi8KKworICAgICAgIC8qIGlu K291dCAqLworI2RlZmluZSBWRklPX0ZCX1NUQVRFX1JFUVVFU1RfVVBEQVRFICAgMSAgLyogdXNl cnNwYWNlIHJlcXVlc3RzIHVwZGF0ZQoqLworI2RlZmluZSBWRklPX0ZCX1NUQVRFX1VQREFURV9D T01QTEVURSAgMiAgLyoga2VybmVsIHNpZ25hbHMgY29tcGxldGlvbgoqLworICAgICAgIF9fdTMy IHN0YXRlOyAgICAgLyogVkZJT19GQl9TVEFURV8gKi8KK307CisKIC8qICoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqICovCiAK ICNlbmRpZiAvKiBfVUFQSVZGSU9fSCAqLwoKY2hlZXJzLAogIEdlcmQKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkludGVsLWdmeCBtYWlsaW5nIGxpc3QK SW50ZWwtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8vbGlzdHMuZnJlZWRlc2t0b3Au b3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756047AbbLDKNj (ORCPT ); Fri, 4 Dec 2015 05:13:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39764 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755177AbbLDKNf convert rfc822-to-8bit (ORCPT ); Fri, 4 Dec 2015 05:13:35 -0500 Message-ID: <1449224012.18669.55.camel@redhat.com> Subject: Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel From: Gerd Hoffmann To: "Tian, Kevin" Cc: Alex Williamson , "Song, Jike" , "xen-devel@lists.xen.org" , "igvt-g@ml01.01.org" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "White, Michael L" , "Dong, Eddie" , "Li, Susie" , "Cowperthwaite, David J" , "Reddy, Raghuveer" , "Zhu, Libo" , "Zhou, Chao" , "Wang, Hongbo" , "Lv, Zhiyuan" , qemu-devel , Paolo Bonzini Date: Fri, 04 Dec 2015 11:13:32 +0100 In-Reply-To: References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com> <54AF967B.3060503@intel.com> <5527CEC4.9080700@intel.com> <559B3E38.1080707@intel.com> <562F4311.9@intel.com> <1447870341.4697.92.camel@redhat.com> <1447922452.25140.39.camel@redhat.com> <1448007960.6904.22.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4nMx-0004q0-A5 for qemu-devel@nongnu.org; Fri, 04 Dec 2015 05:13:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4nMu-00032Z-4U for qemu-devel@nongnu.org; Fri, 04 Dec 2015 05:13:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4nMt-00032O-T0 for qemu-devel@nongnu.org; Fri, 04 Dec 2015 05:13:36 -0500 Message-ID: <1449224012.18669.55.camel@redhat.com> From: Gerd Hoffmann Date: Fri, 04 Dec 2015 11:13:32 +0100 In-Reply-To: References: <53D215D3.50608@intel.com> <547FCAAD.2060406@intel.com> <54AF967B.3060503@intel.com> <5527CEC4.9080700@intel.com> <559B3E38.1080707@intel.com> <562F4311.9@intel.com> <1447870341.4697.92.camel@redhat.com> <1447922452.25140.39.camel@redhat.com> <1448007960.6904.22.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 Subject: Re: [Qemu-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Tian, Kevin" Cc: "igvt-g@ml01.01.org" , "Song, Jike" , "Reddy, Raghuveer" , qemu-devel , "White, Michael L" , "Cowperthwaite, David J" , "intel-gfx@lists.freedesktop.org" , "Li, Susie" , "Dong, Eddie" , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xen.org" , Alex Williamson , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" , "Lv, Zhiyuan" Hi, > btw some questions here: >=20 > 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) =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_ */ +}; + /* ***************************************************************** */ =20 #endif /* _UAPIVFIO_H */ cheers, Gerd