From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel Date: Wed, 18 Nov 2015 11:12:21 -0700 Message-ID: <1447870341.4697.92.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> 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 16B776E600 for ; Wed, 18 Nov 2015 10:12:24 -0800 (PST) In-Reply-To: <562F4311.9@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Jike Song 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 W2NjICtxZW11LWRldmVsLCArcGFvbG8sICtnZXJkXQoKT24gVHVlLCAyMDE1LTEwLTI3IGF0IDE3 OjI1ICswODAwLCBKaWtlIFNvbmcgd3JvdGU6Cj4gSGkgYWxsLAo+IAo+IFdlIGFyZSBwbGVhc2Vk IHRvIGFubm91bmNlIGFub3RoZXIgdXBkYXRlIG9mIEludGVsIEdWVC1nIGZvciBYZW4uCj4gCj4g SW50ZWwgR1ZULWcgaXMgYSBmdWxsIEdQVSB2aXJ0dWFsaXphdGlvbiBzb2x1dGlvbiB3aXRoIG1l ZGlhdGVkCj4gcGFzcy10aHJvdWdoLCBzdGFydGluZyBmcm9tIDR0aCBnZW5lcmF0aW9uIEludGVs IENvcmUoVE0pIHByb2Nlc3NvcnMKPiB3aXRoIEludGVsIEdyYXBoaWNzIHByb2Nlc3NvcnMuIEEg dmlydHVhbCBHUFUgaW5zdGFuY2UgaXMgbWFpbnRhaW5lZAo+IGZvciBlYWNoIFZNLCB3aXRoIHBh cnQgb2YgcGVyZm9ybWFuY2UgY3JpdGljYWwgcmVzb3VyY2VzIGRpcmVjdGx5Cj4gYXNzaWduZWQu IFRoZSBjYXBhYmlsaXR5IG9mIHJ1bm5pbmcgbmF0aXZlIGdyYXBoaWNzIGRyaXZlciBpbnNpZGUg YQo+IFZNLCB3aXRob3V0IGh5cGVydmlzb3IgaW50ZXJ2ZW50aW9uIGluIHBlcmZvcm1hbmNlIGNy aXRpY2FsIHBhdGhzLAo+IGFjaGlldmVzIGEgZ29vZCBiYWxhbmNlIGFtb25nIHBlcmZvcm1hbmNl LCBmZWF0dXJlLCBhbmQgc2hhcmluZwo+IGNhcGFiaWxpdHkuIFhlbiBpcyBjdXJyZW50bHkgc3Vw cG9ydGVkIG9uIEludGVsIFByb2Nlc3NvciBHcmFwaGljcwo+IChhLmsuYS4gWGVuR1QpOyBhbmQg dGhlIGNvcmUgbG9naWMgY2FuIGJlIGVhc2lseSBwb3J0ZWQgdG8gb3RoZXIKPiBoeXBlcnZpc29y cy4KPiAKPiAKPiBSZXBvc2l0b3JpZXMKPiAKPiAgICAgIEtlcm5lbDogaHR0cHM6Ly9naXRodWIu Y29tLzAxb3JnL2lndnRnLWtlcm5lbCAoMjAxNXEzLTMuMTguMCBicmFuY2gpCj4gICAgICBYZW46 IGh0dHBzOi8vZ2l0aHViLmNvbS8wMW9yZy9pZ3Z0Zy14ZW4gKDIwMTVxMy00LjUgYnJhbmNoKQo+ ICAgICAgUWVtdTogaHR0cHM6Ly9naXRodWIuY29tLzAxb3JnL2lndnRnLXFlbXUgKHhlbmd0X3B1 YmxpYzIwMTVxMyBicmFuY2gpCj4gCj4gCj4gVGhpcyB1cGRhdGUgY29uc2lzdHMgb2Y6Cj4gCj4g ICAgICAtIFhlbkdUIGlzIG5vdyBtZXJnZWQgd2l0aCBLVk1HVCBpbiB1bmlmaWVkIHJlcG9zaXRv cmllcyhrZXJuZWwgYW5kIHFlbXUpLCBidXQgY3VycmVudGx5Cj4gICAgICAgIGRpZmZlcmVudCBi cmFuY2hlcyBmb3IgcWVtdS4gIFhlbkdUIGFuZCBLVk1HVCBzaGFyZSBzYW1lIGlHVlQtZyBjb3Jl IGxvZ2ljLgoKSGkhCgpBdCByZWRoYXQgd2UndmUgYmVlbiB0aGlua2luZyBhYm91dCBob3cgdG8g c3VwcG9ydCB2R1BVcyBmcm9tIG11bHRpcGxlCnZlbmRvcnMgaW4gYSBjb21tb24gd2F5IHdpdGhp biBRRU1VLiAgV2Ugd2FudCB0byBlbmFibGUgY29kZSBzaGFyaW5nCmJldHdlZW4gdmVuZG9ycyBh bmQgZ2l2ZSBuZXcgdmVuZG9ycyBhbiBlYXN5IHBhdGggdG8gYWRkIHRoZWlyIG93bgpzdXBwb3J0 LiAgV2UgYWxzbyBoYXZlIHRoZSBjb21wbGljYXRpb24gdGhhdCBub3QgYWxsIHZHUFUgdmVuZG9y cyBhcmUgYXMKb3BlbiBzb3VyY2UgZnJpZW5kbHkgYXMgSW50ZWwsIHNvIGJlaW5nIGFibGUgdG8g YWJzdHJhY3QgdGhlIGRldmljZQptZWRpYXRpb24gYW5kIGFjY2VzcyBvdXRzaWRlIG9mIFFFTVUg aXMgYSBiaWcgYWR2YW50YWdlLgoKVGhlIHByb3Bvc2FsIEknZCBsaWtlIHRvIG1ha2UgaXMgdGhh dCBhIHZHUFUsIHdoZXRoZXIgaXQgaXMgZnJvbSBJbnRlbApvciBhbm90aGVyIHZlbmRvciwgaXMg cHJlZG9taW5hbnRseSBhIFBDSShlKSBkZXZpY2UuICBXZSBoYXZlIGFuCmludGVyZmFjZSBpbiBR RU1VIGFscmVhZHkgZm9yIGV4cG9zaW5nIGFyYml0cmFyeSBQQ0kgZGV2aWNlcywgdmZpby1wY2ku CkN1cnJlbnRseSB2ZmlvLXBjaSB1c2VzIHRoZSBWRklPIEFQSSB0byBpbnRlcmFjdCB3aXRoICJw aHlzaWNhbCIgZGV2aWNlcwphbmQgc3lzdGVtIElPTU1Vcy4gIEkgaGlnaGxpZ2h0IC9waHlzaWNh bC8gdGhlcmUgYmVjYXVzZSBzb21lIG9mIHRoZXNlCnBoeXNpY2FsIGRldmljZXMgYXJlIFNSLUlP ViBWRnMsIHdoaWNoIGlzIHNvbWV3aGF0IG9mIGEgZnV6enkgY29uY2VwdCwKc29tZXdoZXJlIGJl dHdlZW4gZml4ZWQgaGFyZHdhcmUgYW5kIGEgdmlydHVhbCBkZXZpY2UgaW1wbGVtZW50ZWQgaW4K c29mdHdhcmUuICBUaGF0IHNvZnR3YXJlIGp1c3QgaGFwcGVucyB0byBiZSBydW5uaW5nIG9uIHRo ZSBwaHlzaWNhbAplbmRwb2ludC4KCnZHUFVzIGFyZSBzaW1pbGFyLCB3aXRoIHRoZSB2aXJ0dWFs IGRldmljZSBjcmVhdGVkIGF0IGEgZGlmZmVyZW50IHBvaW50LApob3N0IHNvZnR3YXJlLiAgVGhl eSBhbHNvIHJlbHkgb24gZGlmZmVyZW50IElPTU1VIGNvbnN0cnVjdHMsIG1ha2luZyB1c2UKb2Yg dGhlIE1NVSBjYXBhYmlsaXRpZXMgb2YgdGhlIEdQVSAoR1RUcyBhbmQgc3VjaCksIGJ1dCByZWFs bHkgaGF2aW5nCnNpbWlsYXIgcmVxdWlyZW1lbnRzLgoKVGhlIHByb3Bvc2FsIGlzIHRoZXJlZm9y ZSB0aGF0IEdQVSB2ZW5kb3JzIGNhbiBleHBvc2UgdkdQVXMgdG8KdXNlcnNwYWNlLCBhbmQgdGh1 cyB0byBRRU1VLCB1c2luZyB0aGUgVkZJTyBBUEkuICBGb3IgaW5zdGFuY2UsIHZmaW8Kc3VwcG9y dHMgbW9kdWxhciBidXMgZHJpdmVycyBhbmQgSU9NTVUgZHJpdmVycy4gIEFuIGludGVsLXZmaW8t Z3Z0LWQKbW9kdWxlIChvciBleHRlbnNpb24gb2YgaTkxNSkgY2FuIHJlZ2lzdGVyIGFzIGEgdmZp byBidXMgZHJpdmVyLCBjcmVhdGUKYSBzdHJ1Y3QgZGV2aWNlIHBlciB2R1BVLCBjcmVhdGUgYW4g SU9NTVUgZ3JvdXAgZm9yIHRoYXQgZGV2aWNlLCBhbmQKcmVnaXN0ZXIgdGhhdCBkZXZpY2Ugd2l0 aCB0aGUgdmZpby1jb3JlLiAgU2luY2Ugd2UgZG9uJ3QgcmVseSBvbiB0aGUKc3lzdGVtIElPTU1V IGZvciBHVlQtZCB2R1BVIGFzc2lnbm1lbnQsIGFub3RoZXIgdkdQVSB2ZW5kb3IgZHJpdmVyIChv cgpleHRlbnNpb24gb2YgdGhlIHNhbWUgbW9kdWxlKSBjYW4gcmVnaXN0ZXIgYSAidHlwZTEiIGNv bXBsaWFudCBJT01NVQpkcml2ZXIgaW50byB2ZmlvLWNvcmUuICBGcm9tIHRoZSBwZXJzcGVjdGl2 ZSBvZiBRRU1VIHRoZW4sIGFsbCBvZiB0aGUKZXhpc3RpbmcgdmZpby1wY2kgY29kZSBpcyByZS11 c2VkLCBRRU1VIHJlbWFpbnMgbGFyZ2VseSB1bmF3YXJlIG9mIGFueQpzcGVjaWZpY3Mgb2YgdGhl IHZHUFUgYmVpbmcgYXNzaWduZWQsIGFuZCB0aGUgb25seSBuZWNlc3NhcnkgY2hhbmdlIHNvCmZh ciBpcyBob3cgUUVNVSB0cmF2ZXJzZXMgc3lzZnMgdG8gZmluZCB0aGUgZGV2aWNlIGFuZCB0aHVz IHRoZSBJT01NVQpncm91cCBsZWFkaW5nIHRvIHRoZSB2ZmlvIGdyb3VwLgoKVGhlcmUgYXJlIGEg ZmV3IGFyZWFzIHdoZXJlIHdlIGtub3cgd2UnbGwgbmVlZCB0byBleHRlbmQgdGhlIFZGSU8gQVBJ IHRvCm1ha2UgdGhpcyB3b3JrLCBidXQgaXQgc2VlbXMgbGlrZSB0aGV5IGNhbiBhbGwgYmUgZG9u ZSBnZW5lcmljYWxseS4gIE9uZQppcyB0aGF0IFBDSSBCQVJzIGFyZSBkZXNjcmliZWQgdGhyb3Vn aCB0aGUgVkZJTyBBUEkgYXMgcmVnaW9ucyBhbmQgZWFjaApyZWdpb24gaGFzIGEgc2luZ2xlIGZs YWcgZGVzY3JpYmluZyB3aGV0aGVyIG1tYXAgKGllLiBkaXJlY3QgbWFwcGluZykgb2YKdGhhdCBy ZWdpb24gaXMgcG9zc2libGUuICBXZSBleHBlY3QgdGhhdCB2R1BVcyBsaWtlbHkgbmVlZCBmaW5l cgpncmFudWxhcml0eSwgZW5hYmxpbmcgc29tZSBhcmVhcyB3aXRoaW4gYSBCQVIgdG8gYmUgdHJh cHBlZCBhbmQgZm93YXJkZWQKYXMgYSByZWFkIG9yIHdyaXRlIGFjY2VzcyBmb3IgdGhlIHZHUFUt dmZpby1kZXZpY2UgbW9kdWxlIHRvIGVtdWxhdGUsCndoaWxlIG90aGVyIHJlZ2lvbnMsIGxpa2Ug ZnJhbWVidWZmZXJzIG9yIHRleHR1cmUgcmVnaW9ucywgYXJlIGRpcmVjdGx5Cm1hcHBlZC4gIEkg aGF2ZSBwcm90b3R5cGUgY29kZSB0byBlbmFibGUgdGhpcyBhbHJlYWR5LgoKQW5vdGhlciBhcmVh IGlzIHRoYXQgd2UgcmVhbGx5IGRvbid0IHdhbnQgdG8gcHJvbGlmZXJhdGUgZWFjaCB2R1BVCm5l ZWRpbmcgYSBuZXcgSU9NTVUgdHlwZSB3aXRoaW4gdmZpby4gIFRoZSBleGlzdGluZyB0eXBlMSBJ T01NVSBwcm92aWRlcwpwb3RlbnRpYWxseSB0aGUgbW9zdCBzaW1wbGUgbWFwcGluZyBhbmQgdW5t YXBwaW5nIGludGVyZmFjZSBwb3NzaWJsZS4KV2UnZCB0aGVyZWZvcmUgbmVlZCB0byBhbGxvdyBt dWx0aXBsZSAidHlwZTEiIElPTU1VIGRyaXZlcnMgZm9yIHZmaW8sCm1ha2luZyB0eXBlMSBiZSBt b3JlIG9mIGFuIGludGVyZmFjZSBzcGVjaWZpY2F0aW9uIHJhdGhlciB0aGFuIGEgc2luZ2xlCmlt cGxlbWVudGF0aW9uLiAgVGhpcyBpcyBhIHRyaXZpYWwgY2hhbmdlIHRvIG1ha2Ugd2l0aGluIHZm aW8gYW5kIG9uZQp0aGF0IEkgYmVsaWV2ZSBpcyBjb21wYXRpYmxlIHdpdGggdGhlIGV4aXN0aW5n IEFQSS4gIE5vdGUgdGhhdAppbXBsZW1lbnRpbmcgYSB0eXBlMS1jb21wbGlhbnQgdmZpbyBJT01N VSBkb2VzIG5vdCBpbXBseSBwaW5uaW5nIGFuCm1hcHBpbmcgZXZlcnkgcmVnaXN0ZXJlZCBwYWdl LiAgQSB2R1BVLCB3aXRoIG1lZGlhdGVkIGRldmljZSBhY2Nlc3MsIG1heQp1c2UgdGhpcyBvbmx5 IHRvIHRyYWNrIHRoZSBjdXJyZW50IEhWQSB0byBHUEEgbWFwcGluZ3MgZm9yIGEgVk0uICBPbmx5 CndoZW4gYSBETUEgaXMgZW5hYmxlZCBmb3IgdGhlIHZHUFUgaW5zdGFuY2UgaXMgdGhhdCBIVkEg cGlubmVkIGFuZCBhbgpIUEEgdG8gR1BBIHRyYW5zbGF0aW9uIHByb2dyYW1tZWQgaW50byB0aGUg R1BVIE1NVS4KCkFub3RoZXIgYXJlYSBvZiBleHRlbnNpb24gaXMgaG93IHRvIGV4cG9zZSBhIGZy YW1lYnVmZmVyIHRvIFFFTVUgZm9yCnNlYW1sZXNzIGludGVncmF0aW9uIGludG8gYSBTUElDRS9W TkMgY2hhbm5lbC4gIEZvciB0aGlzIEkgYmVsaWV2ZSB3ZQpjb3VsZCB1c2UgYSBuZXcgcmVnaW9u LCBtdWNoIGxpa2Ugd2UndmUgZG9uZSB0byBleHBvc2UgVkdBIGFjY2Vzcwp0aHJvdWdoIGEgdmZp byBkZXZpY2UgZmlsZSBkZXNjcmlwdG9yLiAgQW4gYXJlYSB3aXRoaW4gdGhpcyBuZXcKZnJhbWVi dWZmZXIgcmVnaW9uIGNvdWxkIGJlIGRpcmVjdGx5IG1hcHBhYmxlIGluIFFFTVUgd2hpbGUgYQpu b24tbWFwcGFibGUgcGFnZSwgYXQgYSBzdGFuZGFyZCBsb2NhdGlvbiB3aXRoIHN0YW5kYXJkaXpl ZCBmb3JtYXQsCnByb3ZpZGVzIGEgZGVzY3JpcHRpb24gb2YgZnJhbWVidWZmZXIgYW5kIHBvdGVu dGlhbGx5IGV2ZW4gYQpjb21tdW5pY2F0aW9uIGNoYW5uZWwgdG8gc3luY2hyb25pemUgZnJhbWVi dWZmZXIgY2FwdHVyZXMuICBUaGlzIHdvdWxkCmJlIG5ldyBjb2RlIGZvciBRRU1VLCBidXQgc29t ZXRoaW5nIHdlIGNvdWxkIHNoYXJlIGFtb25nIGFsbCB2R1BVCmltcGxlbWVudGF0aW9ucy4KCkFu b3RoZXIgb2J2aW91cyBhcmVhIHRvIGJlIHN0YW5kYXJkaXplZCB3b3VsZCBiZSBob3cgdG8gZGlz Y292ZXIsCmNyZWF0ZSwgYW5kIGRlc3Ryb3kgdkdQVSBpbnN0YW5jZXMuICBTUi1JT1YgaGFzIGEg c3RhbmRhcmQgbWVjaGFuaXNtIHRvCmNyZWF0ZSBWRnMgaW4gc3lzZnMgYW5kIEkgd291bGQgcHJv cG9zZSB0aGF0IHZHUFUgdmVuZG9ycyB0cnkgdG8Kc3RhbmRhcmRpemUgb24gc2ltaWxhciBpbnRl cmZhY2VzIHRvIGVuYWJsZSBsaWJ2aXJ0IHRvIGVhc2lseSBkaXNjb3Zlcgp0aGUgdkdQVSBjYXBh YmlsaXRpZXMgb2YgYSBnaXZlbiBHUFUgYW5kIG1hbmFnZSB0aGUgbGlmZWN5Y2xlIG9mIGEgdkdQ VQppbnN0YW5jZS4KClRoaXMgaXMgb2J2aW91c2x5IGEgbG90IHRvIGRpZ2VzdCwgYnV0IEknZCBj ZXJ0YWlubHkgYmUgaW50ZXJlc3RlZCBpbgpoZWFyaW5nIGZlZWRiYWNrIG9uIHRoaXMgcHJvcG9z YWwgYXMgd2VsbCBhcyB0cnkgdG8gY2xhcmlmeSBhbnl0aGluZwpJJ3ZlIGxlZnQgb3V0IG9yIG1p c3JlcHJlc2VudGVkIGFib3ZlLiAgQW5vdGhlciBiZW5lZml0IHRvIHRoaXMKbWVjaGFuaXNtIGlz IHRoYXQgZGlyZWN0IEdQVSBhc3NpZ25tZW50IGFuZCB2R1BVIGFzc2lnbm1lbnQgdXNlIHRoZSBz YW1lCmNvZGUgd2l0aGluIFFFTVUgYW5kIHNhbWUgQVBJIHRvIHRoZSBrZXJuZWwsIHdoaWNoIHNo b3VsZCBtYWtlIGRlYnVnZ2luZwphbmQgY29kZSBzdXBwb3J0IGJldHdlZW4gdGhlIHR3byBlYXNp ZXIuICBJJ2QgcmVhbGx5IGxpa2UgdG8gc3RhcnQgYQpkaXNjdXNzaW9uIGFyb3VuZCB0aGlzIHBy b3Bvc2FsLCBhbmQgb2YgY291cnNlIHRoZSBmaXJzdCBvcGVuIHNvdXJjZQppbXBsZW1lbnRhdGlv biBvZiB0aGlzIHNvcnQgb2YgbW9kZWwgd2lsbCByZWFsbHkgaGVscCB0byBkcml2ZSB0aGUKZGly ZWN0aW9uIGl0IHRha2VzLiAgVGhhbmtzIQoKQWxleAoKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4IG1haWxpbmcgbGlzdApJbnRlbC1nZnhA bGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1h bi9saXN0aW5mby9pbnRlbC1nZngK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756608AbbKRSMZ (ORCPT ); Wed, 18 Nov 2015 13:12:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:54808 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756544AbbKRSMX (ORCPT ); Wed, 18 Nov 2015 13:12:23 -0500 Message-ID: <1447870341.4697.92.camel@redhat.com> Subject: Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel From: Alex Williamson To: Jike Song Cc: 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" , "Tian, Kevin" , "Zhu, Libo" , "Zhou, Chao" , "Wang, Hongbo" , Zhiyuan Lv , qemu-devel , Paolo Bonzini , Gerd Hoffmann Date: Wed, 18 Nov 2015 11:12:21 -0700 In-Reply-To: <562F4311.9@intel.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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [cc +qemu-devel, +paolo, +gerd] On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote: > Hi all, > > We are pleased to announce another update of Intel GVT-g for Xen. > > Intel GVT-g is a full GPU virtualization solution with mediated > pass-through, starting from 4th generation Intel Core(TM) processors > with Intel Graphics processors. A virtual GPU instance is maintained > for each VM, with part of performance critical resources directly > assigned. The capability of running native graphics driver inside a > VM, without hypervisor intervention in performance critical paths, > achieves a good balance among performance, feature, and sharing > capability. Xen is currently supported on Intel Processor Graphics > (a.k.a. XenGT); and the core logic can be easily ported to other > hypervisors. > > > Repositories > > Kernel: https://github.com/01org/igvtg-kernel (2015q3-3.18.0 branch) > Xen: https://github.com/01org/igvtg-xen (2015q3-4.5 branch) > Qemu: https://github.com/01org/igvtg-qemu (xengt_public2015q3 branch) > > > This update consists of: > > - XenGT is now merged with KVMGT in unified repositories(kernel and qemu), but currently > different branches for qemu. XenGT and KVMGT share same iGVT-g core logic. Hi! At redhat we've been thinking about how to support vGPUs from multiple vendors in a common way within QEMU. We want to enable code sharing between vendors and give new vendors an easy path to add their own support. We also have the complication that not all vGPU vendors are as open source friendly as Intel, so being able to abstract the device mediation and access outside of QEMU is a big advantage. The proposal I'd like to make is that a vGPU, whether it is from Intel or another vendor, is predominantly a PCI(e) device. We have an interface in QEMU already for exposing arbitrary PCI devices, vfio-pci. Currently vfio-pci uses the VFIO API to interact with "physical" devices and system IOMMUs. I highlight /physical/ there because some of these physical devices are SR-IOV VFs, which is somewhat of a fuzzy concept, somewhere between fixed hardware and a virtual device implemented in software. That software just happens to be running on the physical endpoint. vGPUs are similar, with the virtual device created at a different point, host software. They also rely on different IOMMU constructs, making use of the MMU capabilities of the GPU (GTTs and such), but really having similar requirements. The proposal is therefore that GPU vendors can expose vGPUs to userspace, and thus to QEMU, using the VFIO API. For instance, vfio supports modular bus drivers and IOMMU drivers. An intel-vfio-gvt-d module (or extension of i915) can register as a vfio bus driver, create a struct device per vGPU, create an IOMMU group for that device, and register that device with the vfio-core. Since we don't rely on the system IOMMU for GVT-d vGPU assignment, another vGPU vendor driver (or extension of the same module) can register a "type1" compliant IOMMU driver into vfio-core. From the perspective of QEMU then, all of the existing vfio-pci code is re-used, QEMU remains largely unaware of any specifics of the vGPU being assigned, and the only necessary change so far is how QEMU traverses sysfs to find the device and thus the IOMMU group leading to the vfio group. There are a few areas where we know we'll need to extend the VFIO API to make this work, but it seems like they can all be done generically. One is that PCI BARs are described through the VFIO API as regions and each region has a single flag describing whether mmap (ie. direct mapping) of that region is possible. We expect that vGPUs likely need finer granularity, enabling some areas within a BAR to be trapped and fowarded as a read or write access for the vGPU-vfio-device module to emulate, while other regions, like framebuffers or texture regions, are directly mapped. I have prototype code to enable this already. Another area is that we really don't want to proliferate each vGPU needing a new IOMMU type within vfio. The existing type1 IOMMU provides potentially the most simple mapping and unmapping interface possible. We'd therefore need to allow multiple "type1" IOMMU drivers for vfio, making type1 be more of an interface specification rather than a single implementation. This is a trivial change to make within vfio and one that I believe is compatible with the existing API. Note that implementing a type1-compliant vfio IOMMU does not imply pinning an mapping every registered page. A vGPU, with mediated device access, may use this only to track the current HVA to GPA mappings for a VM. Only when a DMA is enabled for the vGPU instance is that HVA pinned and an HPA to GPA translation programmed into the GPU MMU. Another area of extension is how to expose a framebuffer to QEMU for seamless integration into a SPICE/VNC channel. For this I believe we could use a new region, much like we've done to expose VGA access through a vfio device file descriptor. An area within this new framebuffer region could be directly mappable in QEMU while a non-mappable page, at a standard location with standardized format, provides a description of framebuffer and potentially even a communication channel to synchronize framebuffer captures. This would be new code for QEMU, but something we could share among all vGPU implementations. Another obvious area to be standardized would be how to discover, create, and destroy vGPU instances. SR-IOV has a standard mechanism to create VFs in sysfs and I would propose that vGPU vendors try to standardize on similar interfaces to enable libvirt to easily discover the vGPU capabilities of a given GPU and manage the lifecycle of a vGPU instance. This is obviously a lot to digest, but I'd certainly be interested in hearing feedback on this proposal as well as try to clarify anything I've left out or misrepresented above. Another benefit to this mechanism is that direct GPU assignment and vGPU assignment use the same code within QEMU and same API to the kernel, which should make debugging and code support between the two easier. I'd really like to start a discussion around this proposal, and of course the first open source implementation of this sort of model will really help to drive the direction it takes. Thanks! Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46027) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz7DX-00034S-QL for qemu-devel@nongnu.org; Wed, 18 Nov 2015 13:12:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zz7DU-0007Bs-Hz for qemu-devel@nongnu.org; Wed, 18 Nov 2015 13:12:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:52168) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zz7DU-0007Bm-83 for qemu-devel@nongnu.org; Wed, 18 Nov 2015 13:12:24 -0500 Message-ID: <1447870341.4697.92.camel@redhat.com> From: Alex Williamson Date: Wed, 18 Nov 2015 11:12:21 -0700 In-Reply-To: <562F4311.9@intel.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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Jike Song Cc: igvt-g@ml01.01.org, "Tian, Kevin" , "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, Gerd Hoffmann , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" , Zhiyuan Lv [cc +qemu-devel, +paolo, +gerd] On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote: > Hi all, > > We are pleased to announce another update of Intel GVT-g for Xen. > > Intel GVT-g is a full GPU virtualization solution with mediated > pass-through, starting from 4th generation Intel Core(TM) processors > with Intel Graphics processors. A virtual GPU instance is maintained > for each VM, with part of performance critical resources directly > assigned. The capability of running native graphics driver inside a > VM, without hypervisor intervention in performance critical paths, > achieves a good balance among performance, feature, and sharing > capability. Xen is currently supported on Intel Processor Graphics > (a.k.a. XenGT); and the core logic can be easily ported to other > hypervisors. > > > Repositories > > Kernel: https://github.com/01org/igvtg-kernel (2015q3-3.18.0 branch) > Xen: https://github.com/01org/igvtg-xen (2015q3-4.5 branch) > Qemu: https://github.com/01org/igvtg-qemu (xengt_public2015q3 branch) > > > This update consists of: > > - XenGT is now merged with KVMGT in unified repositories(kernel and qemu), but currently > different branches for qemu. XenGT and KVMGT share same iGVT-g core logic. Hi! At redhat we've been thinking about how to support vGPUs from multiple vendors in a common way within QEMU. We want to enable code sharing between vendors and give new vendors an easy path to add their own support. We also have the complication that not all vGPU vendors are as open source friendly as Intel, so being able to abstract the device mediation and access outside of QEMU is a big advantage. The proposal I'd like to make is that a vGPU, whether it is from Intel or another vendor, is predominantly a PCI(e) device. We have an interface in QEMU already for exposing arbitrary PCI devices, vfio-pci. Currently vfio-pci uses the VFIO API to interact with "physical" devices and system IOMMUs. I highlight /physical/ there because some of these physical devices are SR-IOV VFs, which is somewhat of a fuzzy concept, somewhere between fixed hardware and a virtual device implemented in software. That software just happens to be running on the physical endpoint. vGPUs are similar, with the virtual device created at a different point, host software. They also rely on different IOMMU constructs, making use of the MMU capabilities of the GPU (GTTs and such), but really having similar requirements. The proposal is therefore that GPU vendors can expose vGPUs to userspace, and thus to QEMU, using the VFIO API. For instance, vfio supports modular bus drivers and IOMMU drivers. An intel-vfio-gvt-d module (or extension of i915) can register as a vfio bus driver, create a struct device per vGPU, create an IOMMU group for that device, and register that device with the vfio-core. Since we don't rely on the system IOMMU for GVT-d vGPU assignment, another vGPU vendor driver (or extension of the same module) can register a "type1" compliant IOMMU driver into vfio-core. From the perspective of QEMU then, all of the existing vfio-pci code is re-used, QEMU remains largely unaware of any specifics of the vGPU being assigned, and the only necessary change so far is how QEMU traverses sysfs to find the device and thus the IOMMU group leading to the vfio group. There are a few areas where we know we'll need to extend the VFIO API to make this work, but it seems like they can all be done generically. One is that PCI BARs are described through the VFIO API as regions and each region has a single flag describing whether mmap (ie. direct mapping) of that region is possible. We expect that vGPUs likely need finer granularity, enabling some areas within a BAR to be trapped and fowarded as a read or write access for the vGPU-vfio-device module to emulate, while other regions, like framebuffers or texture regions, are directly mapped. I have prototype code to enable this already. Another area is that we really don't want to proliferate each vGPU needing a new IOMMU type within vfio. The existing type1 IOMMU provides potentially the most simple mapping and unmapping interface possible. We'd therefore need to allow multiple "type1" IOMMU drivers for vfio, making type1 be more of an interface specification rather than a single implementation. This is a trivial change to make within vfio and one that I believe is compatible with the existing API. Note that implementing a type1-compliant vfio IOMMU does not imply pinning an mapping every registered page. A vGPU, with mediated device access, may use this only to track the current HVA to GPA mappings for a VM. Only when a DMA is enabled for the vGPU instance is that HVA pinned and an HPA to GPA translation programmed into the GPU MMU. Another area of extension is how to expose a framebuffer to QEMU for seamless integration into a SPICE/VNC channel. For this I believe we could use a new region, much like we've done to expose VGA access through a vfio device file descriptor. An area within this new framebuffer region could be directly mappable in QEMU while a non-mappable page, at a standard location with standardized format, provides a description of framebuffer and potentially even a communication channel to synchronize framebuffer captures. This would be new code for QEMU, but something we could share among all vGPU implementations. Another obvious area to be standardized would be how to discover, create, and destroy vGPU instances. SR-IOV has a standard mechanism to create VFs in sysfs and I would propose that vGPU vendors try to standardize on similar interfaces to enable libvirt to easily discover the vGPU capabilities of a given GPU and manage the lifecycle of a vGPU instance. This is obviously a lot to digest, but I'd certainly be interested in hearing feedback on this proposal as well as try to clarify anything I've left out or misrepresented above. Another benefit to this mechanism is that direct GPU assignment and vGPU assignment use the same code within QEMU and same API to the kernel, which should make debugging and code support between the two easier. I'd really like to start a discussion around this proposal, and of course the first open source implementation of this sort of model will really help to drive the direction it takes. Thanks! Alex