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: Fri, 20 Nov 2015 10:25:02 -0700 Message-ID: <1448040302.4697.300.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> <1447963356.4697.184.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 D4ED66EB12 for ; Fri, 20 Nov 2015 09:25:04 -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 T24gRnJpLCAyMDE1LTExLTIwIGF0IDA4OjEwICswMDAwLCBUaWFuLCBLZXZpbiB3cm90ZToKPiA+ IEZyb206IFRpYW4sIEtldmluCj4gPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDIwLCAyMDE1IDM6 MTAgUE0KPiAKPiA+ID4gPiA+Cj4gPiA+ID4gPiBUaGUgcHJvcG9zYWwgaXMgdGhlcmVmb3JlIHRo YXQgR1BVIHZlbmRvcnMgY2FuIGV4cG9zZSB2R1BVcyB0bwo+ID4gPiA+ID4gdXNlcnNwYWNlLCBh bmQgdGh1cyB0byBRRU1VLCB1c2luZyB0aGUgVkZJTyBBUEkuICBGb3IgaW5zdGFuY2UsIHZmaW8K PiA+ID4gPiA+IHN1cHBvcnRzIG1vZHVsYXIgYnVzIGRyaXZlcnMgYW5kIElPTU1VIGRyaXZlcnMu ICBBbiBpbnRlbC12ZmlvLWd2dC1kCj4gPiA+ID4gPiBtb2R1bGUgKG9yIGV4dGVuc2lvbiBvZiBp OTE1KSBjYW4gcmVnaXN0ZXIgYXMgYSB2ZmlvIGJ1cyBkcml2ZXIsIGNyZWF0ZQo+ID4gPiA+ID4g YSBzdHJ1Y3QgZGV2aWNlIHBlciB2R1BVLCBjcmVhdGUgYW4gSU9NTVUgZ3JvdXAgZm9yIHRoYXQg ZGV2aWNlLCBhbmQKPiA+ID4gPiA+IHJlZ2lzdGVyIHRoYXQgZGV2aWNlIHdpdGggdGhlIHZmaW8t Y29yZS4gIFNpbmNlIHdlIGRvbid0IHJlbHkgb24gdGhlCj4gPiA+ID4gPiBzeXN0ZW0gSU9NTVUg Zm9yIEdWVC1kIHZHUFUgYXNzaWdubWVudCwgYW5vdGhlciB2R1BVIHZlbmRvciBkcml2ZXIgKG9y Cj4gPiA+ID4gPiBleHRlbnNpb24gb2YgdGhlIHNhbWUgbW9kdWxlKSBjYW4gcmVnaXN0ZXIgYSAi dHlwZTEiIGNvbXBsaWFudCBJT01NVQo+ID4gPiA+ID4gZHJpdmVyIGludG8gdmZpby1jb3JlLiAg RnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgUUVNVSB0aGVuLCBhbGwgb2YgdGhlCj4gPiA+ID4gPiBl eGlzdGluZyB2ZmlvLXBjaSBjb2RlIGlzIHJlLXVzZWQsIFFFTVUgcmVtYWlucyBsYXJnZWx5IHVu YXdhcmUgb2YgYW55Cj4gPiA+ID4gPiBzcGVjaWZpY3Mgb2YgdGhlIHZHUFUgYmVpbmcgYXNzaWdu ZWQsIGFuZCB0aGUgb25seSBuZWNlc3NhcnkgY2hhbmdlIHNvCj4gPiA+ID4gPiBmYXIgaXMgaG93 IFFFTVUgdHJhdmVyc2VzIHN5c2ZzIHRvIGZpbmQgdGhlIGRldmljZSBhbmQgdGh1cyB0aGUgSU9N TVUKPiA+ID4gPiA+IGdyb3VwIGxlYWRpbmcgdG8gdGhlIHZmaW8gZ3JvdXAuCj4gPiA+ID4KPiA+ ID4gPiBHVlQtZyByZXF1aXJlcyB0byBwaW4gZ3Vlc3QgbWVtb3J5IGFuZCBxdWVyeSBHUEEtPkhQ QSBpbmZvcm1hdGlvbiwKPiA+ID4gPiB1cG9uIHdoaWNoIHNoYWRvdyBHVFRzIHdpbGwgYmUgdXBk YXRlZCBhY2NvcmRpbmdseSBmcm9tIChHTUEtPkdQQSkKPiA+ID4gPiB0byAoR01BLT5IUEEpLiBT byB5ZXMsIGhlcmUgYSBkdW1teSBvciBzaW1wbGUgInR5cGUxIiBjb21wbGlhbnQgSU9NTVUKPiA+ ID4gPiBjYW4gYmUgaW50cm9kdWNlZCBqdXN0IGZvciB0aGlzIHJlcXVpcmVtZW50Lgo+ID4gPiA+ Cj4gPiA+ID4gSG93ZXZlciB0aGVyZSdzIG9uZSB0cmlja3kgcG9pbnQgd2hpY2ggSSdtIG5vdCBz dXJlIHdoZXRoZXIgb3ZlcmFsbAo+ID4gPiA+IFZGSU8gY29uY2VwdCB3aWxsIGJlIHZpb2xhdGVk LiBHVlQtZyBkb2Vzbid0IHJlcXVpcmUgc3lzdGVtIElPTU1VCj4gPiA+ID4gdG8gZnVuY3Rpb24s IGhvd2V2ZXIgaG9zdCBzeXN0ZW0gbWF5IGVuYWJsZSBzeXN0ZW0gSU9NTVUganVzdCBmb3IKPiA+ ID4gPiBoYXJkZW5pbmcgcHVycG9zZS4gVGhpcyBtZWFucyB0d28tbGV2ZWwgdHJhbnNsYXRpb25z IGV4aXN0aW5nIChHTUEtPgo+ID4gPiA+IElPVkEtPkhQQSksIHNvIHRoZSBkdW1teSBJT01NVSBk cml2ZXIgaGFzIHRvIHJlcXVlc3Qgc3lzdGVtIElPTU1VCj4gPiA+ID4gZHJpdmVyIHRvIGFsbG9j YXRlIElPVkEgZm9yIFZNcyBhbmQgdGhlbiBzZXR1cCBJT1ZBLT5IUEEgbWFwcGluZwo+ID4gPiA+ IGluIElPTU1VIHBhZ2UgdGFibGUuIEluIHRoaXMgY2FzZSwgbXVsdGlwbGUgVk0ncyB0cmFuc2xh dGlvbnMgYXJlCj4gPiA+ID4gbXVsdGlwbGV4ZWQgaW4gb25lIElPTU1VIHBhZ2UgdGFibGUuCj4g PiA+ID4KPiA+ID4gPiBXZSBtaWdodCBuZWVkIGNyZWF0ZSBzb21lIGdyb3VwL3N1Yi1ncm91cCBv ciBwYXJlbnQvY2hpbGQgY29uY2VwdHMKPiA+ID4gPiBhbW9uZyB0aG9zZSBJT01NVXMgZm9yIHRo b3JvdWdoIHBlcm1pc3Npb24gY29udHJvbC4KPiA+ID4KPiA+ID4gTXkgdGhvdWdodCBoZXJlIGlz IHRoYXQgdGhpcyBpcyBhbGwgYWJzdHJhY3RlZCB0aHJvdWdoIHRoZSB2R1BVIElPTU1VCj4gPiA+ IGFuZCBkZXZpY2UgdmZpbyBiYWNrZW5kcy4gIEl0J3MgdGhlIEdQVSBkcml2ZXIgaXRzZWxmLCBv ciBzb21lIHZmaW8KPiA+ID4gZXh0ZW5zaW9uIG9mIHRoYXQgZHJpdmVyLCBtZWRpYXRpbmcgYWNj ZXNzIHRvIHRoZSBkZXZpY2UgYW5kIGRlY2lkaW5nCj4gPiA+IHdoZW4gdG8gY29uZmlndXJlIEdQ VSBNTVUgbWFwcGluZ3MuICBUaGF0IGRyaXZlciBoYXMgYWNjZXNzIHRvIHRoZSBHUEEKPiA+ID4g dG8gSFZBIHRyYW5zbGF0aW9ucyB0aGFua3MgdG8gdGhlIHR5cGUxIGNvbXBsYWludCBJT01NVSBp dCBpbXBsZW1lbnRzCj4gPiA+IGFuZCBjYW4gcGluIHBhZ2VzIGFzIG5lZWRlZCB0byBjcmVhdGUg R1BBIHRvIEhQQSBtYXBwaW5ncy4gIFRoYXQgc2hvdWxkCj4gPiA+IGdpdmUgaXQgYWxsIHRoZSBw aWVjZXMgaXQgbmVlZHMgdG8gZnVsbHkgc2V0dXAgbWFwcGluZ3MgZm9yIHRoZSB2R1BVLgo+ID4g PiBXaGV0aGVyIG9yIG5vdCB0aGVyZSdzIGEgc3lzdGVtIElPTU1VIGlzIHNpbXBseSBhbiBleGVy Y2lzZSBmb3IgdGhhdAo+ID4gPiBkcml2ZXIuICBJdCBuZWVkcyB0byBkbyBhIERNQSBtYXBwaW5n IG9wZXJhdGlvbiB0aHJvdWdoIHRoZSBzeXN0ZW0gSU9NTVUKPiA+ID4gdGhlIHNhbWUgZm9yIGEg dkdQVSBhcyBpZiBpdCB3YXMgZG9pbmcgaXQgZm9yIGl0c2VsZiwgYmVjYXVzZSB0aGV5IGFyZQo+ ID4gPiBpbiBmYWN0IG9uZSBpbiB0aGUgc2FtZS4gIFRoZSBHTUEgdG8gSU9WQSBtYXBwaW5nIHNl ZW1zIGxpa2UgYW4gaW50ZXJuYWwKPiA+ID4gZGV0YWlsLiAgSSBhc3N1bWUgdGhlIElPVkEgaXMg c29tZSBzb3J0IG9mIEdQQSwgYW5kIHRoZSBHTUEgaXMgbWFuYWdlZAo+ID4gPiB0aHJvdWdoIG1l ZGlhdGlvbiBvZiB0aGUgZGV2aWNlLgo+ID4gCj4gPiBTb3JyeSBJJ20gbm90IGZhbWlsaWFyIHdp dGggVkZJTyBpbnRlcm5hbC4gTXkgb3JpZ2luYWwgd29ycnkgaXMgdGhhdCBzeXN0ZW0KPiA+IElP TU1VIGZvciBHUFUgbWF5IGJlIGFscmVhZHkgY2xhaW1lZCBieSBhbm90aGVyIHZmaW8gZHJpdmVy IChlLmcuIGhvc3Qga2VybmVsCj4gPiB3YW50cyB0byBoYXJkZW4gZ2Z4IGRyaXZlciBmcm9tIHJl c3Qgc3ViLXN5c3RlbXMsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB2R1BVCj4gPiBpcyBjcmVhdGVk IG9yIG5vdCkuIEluIHRoYXQgY2FzZSB2R1BVIElPTU1VIGRyaXZlciBzaG91bGRuJ3QgbWFuYWdl IHN5c3RlbQo+ID4gSU9NTVUgZGlyZWN0bHkuCj4gPiAKPiA+IGJ0dywgY3VyaW91cyB0b2RheSBo b3cgVkZJTyBjb29yZGluYXRlcyB3aXRoIHN5c3RlbSBJT01NVSBkcml2ZXIgcmVnYXJkaW5nCj4g PiB0byB3aGV0aGVyIGEgSU9NTVUgaXMgdXNlZCB0byBjb250cm9sIGRldmljZSBhc3NpZ25tZW50 LCBvciB1c2VkIGZvciBrZXJuZWwKPiA+IGhhcmRlbmluZy4gU29tZWhvdyB0d28gYXJlIGNvbmZs aWN0aW5nIHNpbmNlIGRpZmZlcmVudCBhZGRyZXNzIHNwYWNlcyBhcmUKPiA+IGNvbmNlcm5lZCAo R1BBIHZzLiBJT1ZBKS4uLgo+ID4gCj4gCj4gSGVyZSBpcyBhIG1vcmUgY29uY3JldGUgZXhhbXBs ZToKPiAKPiBLVk1HVCBkb2Vzbid0IHJlcXVpcmUgSU9NTVUuIEFsbCBETUEgdGFyZ2V0cyBhcmUg YWxyZWFkeSByZXBsYWNlZCB3aXRoIAo+IEhQQSB0aHJ1IHNoYWRvdyBHVFQuIFNvIERNQSByZXF1 ZXN0cyBmcm9tIEdQVSBhbGwgY29udGFpbiBIUEFzLgo+IAo+IFdoZW4gSU9NTVUgaXMgZW5hYmxl ZCwgb25lIHNpbXBsZSBhcHByb2FjaCBpcyB0byBoYXZlIHZHUFUgSU9NTVUKPiBkcml2ZXIgY29u ZmlndXJlIHN5c3RlbSBJT01NVSB3aXRoIGlkZW50aXR5IG1hcHBpbmcgKEhQQS0+SFBBKS4gV2Ug Cj4gY2FuJ3QgdXNlIChHUEEtPkhQQSkgc2luY2UgR1BBcyBmcm9tIG11bHRpcGxlIFZNcyBhcmUg Y29uZmxpY3RpbmcuIAo+IAo+IEhvd2V2ZXIsIHdlIHN0aWxsIGhhdmUgaG9zdCBnZnggZHJpdmVy IHJ1bm5pbmcuIFdoZW4gSU9NTVUgaXMgZW5hYmxlZCwgCj4gZG1hX2FsbG9jXyoqKiB3aWxsIHJl dHVybiBJT1ZBIChkcnZlcnMvaW9tbXUvaW92YS5jKSBpbiBob3N0IGdmeCBkcml2ZXIsCj4gd2hp Y2ggd2lsbCBoYXZlIElPVkEtPkhQQSBwcm9ncmFtbWVkIHRvIHN5c3RlbSBJT01NVS4KPiAKPiBP bmUgSU9NTVUgZGV2aWNlIGVudHJ5IGNhbiBvbmx5IHRyYW5zbGF0ZSBvbmUgYWRkcmVzcyBzcGFj ZSwgc28gaGVyZQo+IGNvbWVzIGEgY29uZmxpY3QgKEhQQS0+SFBBIHZzLiBJT1ZBLT5IUEEpLiBU byBzb2x2ZSB0aGlzLCB2R1BVIElPTU1VCj4gZHJpdmVyIG5lZWRzIHRvIGFsbG9jYXRlIElPVkEg ZnJvbSBpb3ZhLmMgZm9yIGVhY2ggVk0gdy8gdkdQVSBhc3NpZ25lZCwKPiBhbmQgdGhlbiBLVk1H VCB3aWxsIHByb2dyYW0gSU9WQSBpbiBzaGFkb3cgR1RUIGFjY29yZGluZ2x5LiBJdCBhZGRzCj4g b25lIGFkZGl0aW9uYWwgbWFwcGluZyBsYXllciAoR1BBLT5JT1ZBLT5IUEEpLiBJbiB0aGlzIHdh eSB0d28gCj4gcmVxdWlyZW1lbnRzIGNhbiBiZSB1bmlmaWVkIHRvZ2V0aGVyIHNpbmNlIG9ubHkg SU9WQS0+SFBBIG1hcHBpbmcgCj4gbmVlZHMgdG8gYmUgYnVpbHQuCj4gCj4gU28gdW5saWtlIGV4 aXN0aW5nIHR5cGUxIElPTU1VIGRyaXZlciB3aGljaCBjb250cm9scyBJT01NVSBhbG9uZSwgdkdQ VSAKPiBJT01NVSBkcml2ZXIgbmVlZHMgdG8gY29vcGVyYXRlIHdpdGggb3RoZXIgYWdlbnQgKGlv dmEuYyBoZXJlKSB0bwo+IGNvLW1hbmFnZSBzeXN0ZW0gSU9NTVUuIFRoaXMgbWF5IG5vdCBpbXBh Y3QgZXhpc3RpbmcgVkZJTyBmcmFtZXdvcmsuCj4gSnVzdCB3YW50IHRvIGhpZ2hsaWdodCBhZGRp dGlvbmFsIHdvcmsgaGVyZSB3aGVuIGltcGxlbWVudGluZyB0aGUgdkdQVQo+IElPTU1VIGRyaXZl ci4KClJpZ2h0LCBzbyB0aGUgZXhpc3RpbmcgaTkxNSBkcml2ZXIgbmVlZHMgdG8gdXNlIHRoZSBE TUEgQVBJIGFuZCBjYWxscwpsaWtlIGRtYV9tYXBfcGFnZSgpIHRvIGVuYWJsZSB0cmFuc2xhdGlv bnMgdGhyb3VnaCB0aGUgSU9NTVUuICBXaXRoCmRtYV9tYXBfcGFnZSgpLCB0aGUgY2FsbGVyIHBy b3ZpZGVzIGEgcGFnZSBhZGRyZXNzICh+SFBBKSBhbmQgaXMKcmV0dXJuZWQgYW4gSU9WQS4gIFNv IHVuZm9ydHVuYXRlbHkgeW91IGRvbid0IGdldCB0byB0YWtlIHRoZSBzaG9ydGN1dApvZiBoYXZp bmcgYW4gaWRlbnRpdHkgbWFwcGluZyB0aHJvdWdoIHRoZSBJT01NVSB1bmxlc3MgeW91IHdhbnQg dG8KY29udmVydCBpOTE1IGVudGlyZWx5IHRvIHVzaW5nIHRoZSBJT01NVSBBUEksIGJlY2F1c2Ug d2UgYWxzbyBjYW4ndCBoYXZlCnRoZSBjb25mbGljdCB0aGF0IGFuIEhQQSBjb3VsZCBvdmVybGFw IGFuIElPVkEgZm9yIGEgcHJldmlvdXNseSBtYXBwZWQKcGFnZS4KClRoZSBkb3VibGUgdHJhbnNs YXRpb24sIG9uY2UgdGhyb3VnaCB0aGUgR1BVIE1NVSBhbmQgb25jZSB0aHJvdWdoIHRoZQpzeXN0 ZW0gSU9NTVUgaXMgZ29pbmcgdG8gaGFwcGVuIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB3ZSBjYW4g aWRlbnRpdHkKbWFwIHRocm91Z2ggdGhlIElPTU1VLiAgVGhlIG9ubHkgc29sdXRpb24gdG8gdGhp cyB3b3VsZCBiZSBmb3IgdGhlIEdQVQp0byBwYXJ0aWNpcGF0ZSBpbiBBVFMgYW5kIHByb3ZpZGUg cHJlLXRyYW5zbGF0ZWQgdHJhbnNhY3Rpb25zIGZyb20gdGhlCkdQVS4gIEFsbCBvZiB0aGlzIGlz IGludGVybmFsIHRvIHRoZSBpOTE1IGRyaXZlciAob3IgdmZpbyBleHRlbnNpb24gb2YKdGhhdCBk cml2ZXIpIGFuZCBuZWVkcyB0byBiZSBkb25lIHJlZ2FyZGxlc3Mgb2Ygd2hhdCBzb3J0IG9mIGlu dGVyZmFjZQp3ZSdyZSB1c2luZyB0byBleHBvc2UgdGhlIHZHUFUgdG8gUUVNVS4gIEl0IGp1c3Qg c2VlbXMgbGlrZSBWRklPCnByb3ZpZGVzIGEgY29udmVuaWVudCB3YXkgb2YgZG9pbmcgdGhpcyBz aW5jZSB5b3UnbGwgaGF2ZSByZWFkeSBhY2Nlc3MKdG8gdGhlIEhWQS1HUEEgbWFwcGluZ3MgZm9y IHRoZSB1c2VyLgoKSSB0aGluayB0aGUga2V5IHBvaW50cyB0aG91Z2ggYXJlOgoKICAgICAgKiB0 aGUgVkZJTyB0eXBlMSBJT01NVSBzdG9yZXMgR1BBIHRvIEhWQSB0cmFuc2xhdGlvbnMKICAgICAg KiBnZXRfdXNlcl9wYWdlcygpIG9uIHRoZSBIVkEgd2lsbCBwaW4gdGhlIHBhZ2UgYW5kIGdpdmUg eW91IGEKICAgICAgICBwYWdlCiAgICAgICogZG1hX21hcF9wYWdlKCkgcmVjZWl2ZXMgdGhhdCBw YWdlLCBwcm9ncmFtcyB0aGUgc3lzdGVtIElPTU1VIGFuZAogICAgICAgIHByb3ZpZGVzIGFuIElP VkEKICAgICAgKiB0aGUgR1BVIE1NVSBjYW4gdGhlbiBiZSBwcm9ncmFtbWVkIHdpdGggdGhlIEdQ QSB0byBJT1ZBCiAgICAgICAgdHJhbnNsYXRpb25zCgpUaGFua3MsCkFsZXgKCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkludGVsLWdmeCBtYWlsaW5nIGxp c3QKSW50ZWwtZ2Z4QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwOi8vbGlzdHMuZnJlZWRlc2t0 b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1163312AbbKTRZI (ORCPT ); Fri, 20 Nov 2015 12:25:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48230 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751713AbbKTRZE (ORCPT ); Fri, 20 Nov 2015 12:25:04 -0500 Message-ID: <1448040302.4697.300.camel@redhat.com> Subject: Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel From: Alex Williamson To: "Tian, Kevin" Cc: "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 , Gerd Hoffmann Date: Fri, 20 Nov 2015 10:25:02 -0700 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> <1447963356.4697.184.camel@redhat.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 On Fri, 2015-11-20 at 08:10 +0000, Tian, Kevin wrote: > > From: Tian, Kevin > > Sent: Friday, November 20, 2015 3:10 PM > > > > > > > > > > > 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. > > > > > > > > GVT-g requires to pin guest memory and query GPA->HPA information, > > > > upon which shadow GTTs will be updated accordingly from (GMA->GPA) > > > > to (GMA->HPA). So yes, here a dummy or simple "type1" compliant IOMMU > > > > can be introduced just for this requirement. > > > > > > > > However there's one tricky point which I'm not sure whether overall > > > > VFIO concept will be violated. GVT-g doesn't require system IOMMU > > > > to function, however host system may enable system IOMMU just for > > > > hardening purpose. This means two-level translations existing (GMA-> > > > > IOVA->HPA), so the dummy IOMMU driver has to request system IOMMU > > > > driver to allocate IOVA for VMs and then setup IOVA->HPA mapping > > > > in IOMMU page table. In this case, multiple VM's translations are > > > > multiplexed in one IOMMU page table. > > > > > > > > We might need create some group/sub-group or parent/child concepts > > > > among those IOMMUs for thorough permission control. > > > > > > My thought here is that this is all abstracted through the vGPU IOMMU > > > and device vfio backends. It's the GPU driver itself, or some vfio > > > extension of that driver, mediating access to the device and deciding > > > when to configure GPU MMU mappings. That driver has access to the GPA > > > to HVA translations thanks to the type1 complaint IOMMU it implements > > > and can pin pages as needed to create GPA to HPA mappings. That should > > > give it all the pieces it needs to fully setup mappings for the vGPU. > > > Whether or not there's a system IOMMU is simply an exercise for that > > > driver. It needs to do a DMA mapping operation through the system IOMMU > > > the same for a vGPU as if it was doing it for itself, because they are > > > in fact one in the same. The GMA to IOVA mapping seems like an internal > > > detail. I assume the IOVA is some sort of GPA, and the GMA is managed > > > through mediation of the device. > > > > Sorry I'm not familiar with VFIO internal. My original worry is that system > > IOMMU for GPU may be already claimed by another vfio driver (e.g. host kernel > > wants to harden gfx driver from rest sub-systems, regardless of whether vGPU > > is created or not). In that case vGPU IOMMU driver shouldn't manage system > > IOMMU directly. > > > > btw, curious today how VFIO coordinates with system IOMMU driver regarding > > to whether a IOMMU is used to control device assignment, or used for kernel > > hardening. Somehow two are conflicting since different address spaces are > > concerned (GPA vs. IOVA)... > > > > Here is a more concrete example: > > KVMGT doesn't require IOMMU. All DMA targets are already replaced with > HPA thru shadow GTT. So DMA requests from GPU all contain HPAs. > > When IOMMU is enabled, one simple approach is to have vGPU IOMMU > driver configure system IOMMU with identity mapping (HPA->HPA). We > can't use (GPA->HPA) since GPAs from multiple VMs are conflicting. > > However, we still have host gfx driver running. When IOMMU is enabled, > dma_alloc_*** will return IOVA (drvers/iommu/iova.c) in host gfx driver, > which will have IOVA->HPA programmed to system IOMMU. > > One IOMMU device entry can only translate one address space, so here > comes a conflict (HPA->HPA vs. IOVA->HPA). To solve this, vGPU IOMMU > driver needs to allocate IOVA from iova.c for each VM w/ vGPU assigned, > and then KVMGT will program IOVA in shadow GTT accordingly. It adds > one additional mapping layer (GPA->IOVA->HPA). In this way two > requirements can be unified together since only IOVA->HPA mapping > needs to be built. > > So unlike existing type1 IOMMU driver which controls IOMMU alone, vGPU > IOMMU driver needs to cooperate with other agent (iova.c here) to > co-manage system IOMMU. This may not impact existing VFIO framework. > Just want to highlight additional work here when implementing the vGPU > IOMMU driver. Right, so the existing i915 driver needs to use the DMA API and calls like dma_map_page() to enable translations through the IOMMU. With dma_map_page(), the caller provides a page address (~HPA) and is returned an IOVA. So unfortunately you don't get to take the shortcut of having an identity mapping through the IOMMU unless you want to convert i915 entirely to using the IOMMU API, because we also can't have the conflict that an HPA could overlap an IOVA for a previously mapped page. The double translation, once through the GPU MMU and once through the system IOMMU is going to happen regardless of whether we can identity map through the IOMMU. The only solution to this would be for the GPU to participate in ATS and provide pre-translated transactions from the GPU. All of this is internal to the i915 driver (or vfio extension of that driver) and needs to be done regardless of what sort of interface we're using to expose the vGPU to QEMU. It just seems like VFIO provides a convenient way of doing this since you'll have ready access to the HVA-GPA mappings for the user. I think the key points though are: * the VFIO type1 IOMMU stores GPA to HVA translations * get_user_pages() on the HVA will pin the page and give you a page * dma_map_page() receives that page, programs the system IOMMU and provides an IOVA * the GPU MMU can then be programmed with the GPA to IOVA translations Thanks, Alex From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45476) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzpQq-00043p-Iy for qemu-devel@nongnu.org; Fri, 20 Nov 2015 12:25:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzpQn-0007k1-3p for qemu-devel@nongnu.org; Fri, 20 Nov 2015 12:25:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzpQm-0007jM-Pc for qemu-devel@nongnu.org; Fri, 20 Nov 2015 12:25:05 -0500 Message-ID: <1448040302.4697.300.camel@redhat.com> From: Alex Williamson Date: Fri, 20 Nov 2015 10:25:02 -0700 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> <1447963356.4697.184.camel@redhat.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: "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" , Gerd Hoffmann , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" , "Lv, Zhiyuan" On Fri, 2015-11-20 at 08:10 +0000, Tian, Kevin wrote: > > From: Tian, Kevin > > Sent: Friday, November 20, 2015 3:10 PM > > > > > > > > > > > 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. > > > > > > > > GVT-g requires to pin guest memory and query GPA->HPA information, > > > > upon which shadow GTTs will be updated accordingly from (GMA->GPA) > > > > to (GMA->HPA). So yes, here a dummy or simple "type1" compliant IOMMU > > > > can be introduced just for this requirement. > > > > > > > > However there's one tricky point which I'm not sure whether overall > > > > VFIO concept will be violated. GVT-g doesn't require system IOMMU > > > > to function, however host system may enable system IOMMU just for > > > > hardening purpose. This means two-level translations existing (GMA-> > > > > IOVA->HPA), so the dummy IOMMU driver has to request system IOMMU > > > > driver to allocate IOVA for VMs and then setup IOVA->HPA mapping > > > > in IOMMU page table. In this case, multiple VM's translations are > > > > multiplexed in one IOMMU page table. > > > > > > > > We might need create some group/sub-group or parent/child concepts > > > > among those IOMMUs for thorough permission control. > > > > > > My thought here is that this is all abstracted through the vGPU IOMMU > > > and device vfio backends. It's the GPU driver itself, or some vfio > > > extension of that driver, mediating access to the device and deciding > > > when to configure GPU MMU mappings. That driver has access to the GPA > > > to HVA translations thanks to the type1 complaint IOMMU it implements > > > and can pin pages as needed to create GPA to HPA mappings. That should > > > give it all the pieces it needs to fully setup mappings for the vGPU. > > > Whether or not there's a system IOMMU is simply an exercise for that > > > driver. It needs to do a DMA mapping operation through the system IOMMU > > > the same for a vGPU as if it was doing it for itself, because they are > > > in fact one in the same. The GMA to IOVA mapping seems like an internal > > > detail. I assume the IOVA is some sort of GPA, and the GMA is managed > > > through mediation of the device. > > > > Sorry I'm not familiar with VFIO internal. My original worry is that system > > IOMMU for GPU may be already claimed by another vfio driver (e.g. host kernel > > wants to harden gfx driver from rest sub-systems, regardless of whether vGPU > > is created or not). In that case vGPU IOMMU driver shouldn't manage system > > IOMMU directly. > > > > btw, curious today how VFIO coordinates with system IOMMU driver regarding > > to whether a IOMMU is used to control device assignment, or used for kernel > > hardening. Somehow two are conflicting since different address spaces are > > concerned (GPA vs. IOVA)... > > > > Here is a more concrete example: > > KVMGT doesn't require IOMMU. All DMA targets are already replaced with > HPA thru shadow GTT. So DMA requests from GPU all contain HPAs. > > When IOMMU is enabled, one simple approach is to have vGPU IOMMU > driver configure system IOMMU with identity mapping (HPA->HPA). We > can't use (GPA->HPA) since GPAs from multiple VMs are conflicting. > > However, we still have host gfx driver running. When IOMMU is enabled, > dma_alloc_*** will return IOVA (drvers/iommu/iova.c) in host gfx driver, > which will have IOVA->HPA programmed to system IOMMU. > > One IOMMU device entry can only translate one address space, so here > comes a conflict (HPA->HPA vs. IOVA->HPA). To solve this, vGPU IOMMU > driver needs to allocate IOVA from iova.c for each VM w/ vGPU assigned, > and then KVMGT will program IOVA in shadow GTT accordingly. It adds > one additional mapping layer (GPA->IOVA->HPA). In this way two > requirements can be unified together since only IOVA->HPA mapping > needs to be built. > > So unlike existing type1 IOMMU driver which controls IOMMU alone, vGPU > IOMMU driver needs to cooperate with other agent (iova.c here) to > co-manage system IOMMU. This may not impact existing VFIO framework. > Just want to highlight additional work here when implementing the vGPU > IOMMU driver. Right, so the existing i915 driver needs to use the DMA API and calls like dma_map_page() to enable translations through the IOMMU. With dma_map_page(), the caller provides a page address (~HPA) and is returned an IOVA. So unfortunately you don't get to take the shortcut of having an identity mapping through the IOMMU unless you want to convert i915 entirely to using the IOMMU API, because we also can't have the conflict that an HPA could overlap an IOVA for a previously mapped page. The double translation, once through the GPU MMU and once through the system IOMMU is going to happen regardless of whether we can identity map through the IOMMU. The only solution to this would be for the GPU to participate in ATS and provide pre-translated transactions from the GPU. All of this is internal to the i915 driver (or vfio extension of that driver) and needs to be done regardless of what sort of interface we're using to expose the vGPU to QEMU. It just seems like VFIO provides a convenient way of doing this since you'll have ready access to the HVA-GPA mappings for the user. I think the key points though are: * the VFIO type1 IOMMU stores GPA to HVA translations * get_user_pages() on the HVA will pin the page and give you a page * dma_map_page() receives that page, programs the system IOMMU and provides an IOVA * the GPU MMU can then be programmed with the GPA to IOVA translations Thanks, Alex