From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [PATCH v9 5/7] vfio: Define vfio based dma-buf operations Date: Thu, 22 Jun 2017 10:30:15 +0200 Message-ID: <1498120215.25651.5.camel@redhat.com> References: <1497513611-2814-1-git-send-email-xiaoguang.chen@intel.com> <1497513611-2814-6-git-send-email-xiaoguang.chen@intel.com> <1497542438.29252.1.camel@redhat.com> <20170615143833.7526351b@w520.home> <24c4880b-24f5-ea07-834c-c77d3e895c78@nvidia.com> <1497854312.4207.4.camel@redhat.com> <20170619085530.1f5e46dc@w520.home> <237F54289DF84E4997F34151298ABEBC7C56EBE0@SHSMSX101.ccr.corp.intel.com> <1497956256.16795.7.camel@redhat.com> <20170620090004.44ac7fbc@w520.home> <237F54289DF84E4997F34151298ABEBC7C56F3DC@SHSMSX101.ccr.corp.intel.com> <20170620172204.09405cf4@w520.home> <237F54289DF84E4997F34151298ABEBC7C56F843@SHSMSX101.ccr.corp.intel.com> <1498043011.5802.5.camel@redhat.com> <20170621125938.1a92abda@w520.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20170621125938.1a92abda@w520.home> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Alex Williamson Cc: "Wang, Zhenyu Z" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "Chen, Xiaoguang" , Kirti Wankhede , "Lv, Zhiyuan" , "intel-gvt-dev@lists.freedesktop.org" List-Id: intel-gfx@lists.freedesktop.org ICBIaSwKCj4gPiBWRklPX0RFVklDRV9GTEFHU19HRlhfRE1BQlVGPwo+IAo+IEFmdGVyIHByb3Bv c2luZyB0aGVzZSwgSSdtIGtpbmQgb2YgcXVlc3Rpb25pbmcgdGhlaXIgcHVycG9zZS7CoMKgSW4g dGhlCj4gY2FzZSBvZiBhIEdGWCByZWdpb24sIHRoZSB1c2VyIGlzIGdvaW5nIHRvIGxlYXJuIHRo YXQgdGhpcyBpcwo+IHN1cHBvcnRlZAo+IGFzIHRoZXkgcGFyc2UgdGhlIHJlZ2lvbiBpbmZvcm1h dGlvbiBhbmQgZmluZCB0aGUgZGV2aWNlIHNwZWNpZmljCj4gcmVnaW9uIGlkZW50aWZ5aW5nIGl0 c2VsZiBhcyBhIEdGWCBhcmVhLsKgwqBUaGF0IG5lZWRzIHRvIGhhcHBlbiBlYXJseQo+IHdoZW4g dGhlIHVzZXIgaXMgZXZhbHVhdGluZyB0aGUgZGV2aWNlLCBzbyBpdCBzZWVtcyByYXRoZXIgcmVk dW5kYW50Cj4gdG8gdGhlIGZsYWcuCgpJbmRlZWQuCgo+IElmIHdlIGhhdmUgZG1hYnVmIHN1cHBv cnQsIGlzbid0IHRoYXQgaW5kaWNhdGVkIGJ5IHRyeWluZyB0byBxdWVyeQo+IHRoZQo+IGdyYXBo aWNzIHBsYW5lX2luZm8gYW5kIGdldHRpbmcgYmFjayBhIHJlc3VsdCBpbmRpY2F0aW5nIGEgZG1h YnVmIGZkPwo+IElzIHRoZXJlIGFueSBwb2ludCBpbiB0aW1lIHdoZXJlIGEgZGV2aWNlIHN1cHBv cnRpbmcgZG1hYnVmIGZkcyB3b3VsZAo+IG5vdCByZXBvcnQgdGhpcyBoZXJlP8KgwqBVc2Vyc3Bh Y2UgY291bGQgcmVhbGx5IGRvIHRoZSBzYW1lIHByb2Nlc3MgZm9yCj4gYQo+IGdyYXBoaWNzIHJl Z2lvbiwgaWUuIHF1ZXJ5aW5nIHRoZSBwbGFuZV9pbmZvLCBpZiBpdCBleGlzdHMgcHVyc3VpbmcK PiBlaXRoZXIgdGhlIHJlZ2lvbiBvciBkbWFidWYgcGF0aCB0byBnZXQgaXQuCgpXZWxsLCB5b3Ug Y2FuIGdldCBhIGRtYS1idWYgb25seSBhZnRlciB0aGUgZ3Vlc3QgbG9hZGVkIHRoZSBkcml2ZXIg YW5kCmluaXRpYWxpemVkIHRoZSBkZXZpY2UsIHNvIGEgcGxhbmUgYWN0dWFsbHkgZXhpc3RzIC4u LgoKUmlnaHQgbm93IHRoZSBleHBlcmltZW50YWwgaW50ZWwgcGF0Y2hlcyB0aHJvdyBlcnJvcnMg aW4gY2FzZSBubyBwbGFuZQpleGlzdHMgKHlldCkuICBNYXliZSB3ZSBzaG91bGQgaGF2ZSBhICJi b29sIGlzX2VuYWJsZWQiIGZpZWxkIGluIHRoZQpwbGFuZV9pbmZvIHN0cnVjdCwgc28gZHJpdmVy cyBjYW4gdXNlIHRoYXQgdG8gc2lnbmFsIHdoZW5ldmVyIHRoZSBndWVzdApoYXMgcHJvZ3JhbW1l ZCBhIHZhbGlkIHZpZGVvIG1vZGUgb3Igbm90IChsaWtld2lzZSBmb3IgdGhlIGN1cnNvciwKd2hp Y2ggZG9lc24ndCBleGlzdCB3aXRoIGZiY29uLCBvbmx5IHdoZW4gcnVubmluZyB4b3JnKS4gIFdp dGggdGhhdCBpbgpwbGFjZSB1c2luZyB0aGUgUVVFUllfUExBTkUgaW9jdGwgYWxzbyBmb3IgcHJv YmluZyBsb29rcyByZWFzb25hYmxlLgoKPiA+IGdlbmVyYXRpb24gd291bGQgYmUgaW5jcmVhc2Vk IGVhY2ggdGltZSBvbmUgb2YgdGhlIGZpZWxkcyBpbgo+ID4gdmZpb19kZXZpY2VfZ2Z4X3BsYW5l X2luZm8gY2hhbmdlcywgdHlwaWNhbGx5IG9uIG1vZGUgc3dpdGNoZXMKPiA+ICh3aWR0aC9oZWln aHQgY2hhbmdlcykgYW5kIHBhZ2VmbGlwcyAob2Zmc2V0IGNoYW5nZXMpLsKgwqBTbwo+ID4gdXNl cnNwYWNlCj4gPiBjYW4gc2ltcGx5IGNvbXBhcmUgZ2VuZXJhdGlvbiBpbnN0ZWFkIG9mIGNvbXBh cmluZyBldmVyeSBmaWVsZCB0bwo+ID4gZmlndXJlIHdoZW5ldmVyIHNvbWV0aGluZyBjaGFuZ2Vk IGNvbXBhcmVkIHRvIHRoZSBwcmV2aW91cyBwb2xsLgo+IAo+IFNvIHdlIGhhdmUgdHdvIHNjZW5h cmlvcywgZG1hYnVmIGFuZCByZWdpb24uwqDCoFdoZW4gdGhlIHVzZXIgcmV0cmlldmVzCj4gYQo+ IGRtYWJ1ZiB0aGV5IGdldCBwbGFuZV9pbmZvIHdoaWNoIGluY2x1ZGVzIHRoZSBnZW5lcmF0aW9u LCBzbyB0aGV5Cj4ga25vdwo+IHRoZSBkbWFidWYgaXMgZm9yIHRoYXQgZ2VuZXJhdGlvbi7CoMKg SWYgdGhleSBxdWVyeSB0aGUgcGxhbmVfaW5mbyBhbmQKPiBnZXQgYSBkaWZmZXJlbnQgZ2VuZXJh dGlvbiB0aGV5IHNob3VsZCBjbG9zZSB0aGUgcHJldmlvdXMgZG1hYnVmIGFuZAo+IGdldCBhbm90 aGVyLgoKS2VlcGluZyBpdCBjYWNoZWQgaXMgYSB2YWxpZCBjaG9pY2UgdG9vLgoKPiBEb2VzIHRo aXMgcHJvbW90ZSB0aGUgY2FjaGluZyBpZGVhIHRoYXQgYSB1c2VyIG1pZ2h0Cj4gbWFpbnRhaW4g bXVsdGlwbGUgb3BlbiBkbWFidWYgZmRzIGFuZCBzZWxlY3QgdGhlIGFwcHJvcHJpYXRlIG9uZSBm b3IKPiB0aGUgY3VycmVudCBkZXZpY2Ugc3RhdGU/wqDCoElzIGl0IGVudGlyZWx5IHRoZSB1c2Vy J3MgcmVzcG9uc2liaWxpdHkKPiB0bwo+IHJlbWVtYmVyIHRoZSBwbGFuZSBpbmZvIGZvciBhbiBv cGVuIGRtYWJ1ZiBmZD8KClllcywgSSdkIGxlYXZlIHRoYXQgdG8gdXNlcnNwYWNlLiAgU28sIHdo ZW4gdGhlIGdlbmVyYXRpb24gY2hhbmdlcwp1c2Vyc3BhY2Uga25vd3MgdGhlIGd1ZXN0IGNoYW5n ZWQgdGhlIHBsYW5lLiAgSXQgY291bGQgYmUgYQpjb25maWd1cmF0aW9uIHRoZSBndWVzdCBoYXMg dXNlZCBiZWZvcmUgKGFuZCB3aGVyZSB1c2Vyc3BhY2UgY291bGQgaGF2ZQphIGNhY2hlZCBkbWEt YnVmIGhhbmRsZSBmb3IpLCBvciBpdCBjb3VsZCBiZSBzb21ldGhpbmcgbmV3LgoKPiBXaGF0IGhh cHBlbnMgdG8KPiBleGlzdGluZyBkbWFidWYgZmRzIHdoZW4gdGhlIGdlbmVyYXRpb24gdXBkYXRl cywgZG8gdGhleSBzdG9wCj4gcmVmcmVzaGluZz8KCkRlcGVuZHMgb24gd2hhdCB0aGUgZ3Vlc3Qg aXMgZG9pbmcgOykKClRoZSBkbWEtYnVmIGlzIGp1c3QgYSBob3N0LXNpZGUgaGFuZGxlIGZvciB0 aGUgcGllY2Ugb2YgdmlkZW8gbWVtb3J5CndoZXJlIHRoZSBndWVzdCBzdG9yZWQgdGhlIGZyYW1l YnVmZmVyLgoKPiBEb2VzIGl0IGJsYW5rIHRoZSBmcmFtZWJ1ZmZlcj8KCk5vLgoKPiBDYW4gdGhl IGRtYWJ1ZiBmZAo+IHRyYW5zcGFyZW50bHkgdXBkYXRlIHRvIHRoZSBuZXcgcGxhbmVfaW5mbz8K Ck5vLgoKPiBUaGUgb3RoZXIgY2FzZSBpcyBhIHJlZ2lvbiwgdGhlIHVzZXIgcXVlcmllcyB0aGUg cGxhbmVfaW5mbyByZWNvcmRzCj4gdGhlCj4gcGFyYW1ldGVycyBhbmQgcmVnaW9uIGluZm8sIGFu ZCBjb25maWd1cmVzIGFjY2VzcyB0byB0aGUgcmVnaW9uIHVzaW5nCj4gdGhhdCBpbmZvcm1hdGlv bi7CoMKgTWVhbndoaWxlLCBzb21ldGhpbmcgY2hhbmdlZCwgcGxhbmVfaW5mbyBpbmNsdWRpbmcK PiBnZW5lcmF0aW9uIGlzIHVwZGF0ZWQsIGJ1dCB0aGUgdXNlciBpcyBzdGlsbCBhc3N1bWluZyB0 aGUgcHJldmlvdXMKPiBwbGFuZV9pbmZvLsKgwqBIb3cgY2FuIHdlIGF2b2lkIHN1Y2ggYSByYWNl PwoKUWVtdSBkb2Vzbid0LiAgWW91IG1pZ2h0IGdldCByZW5kZXJpbmcgZ2xpdGNoZXMgaW4gdGhh dCBjYXNlLCBkdWUgdG8KYWNjZXNzaW5nIHRoZSBwbGFuZSB3aXRoIHRoZSB3cm9uZyBjb25maWd1 cmF0aW9uLiAgSXQncyBmdW5kYW1lbnRhbGx5CnRoZSBzYW1lIHdpdGggc3RkdmdhIGJ0dy4KCj4g V2hhdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkKPiBvZiB0aGUgdXNlciBhbmQgaG93IGFyZSB0aGV5 IG5vdGlmaWVkIHRvIHJlZnJlc2ggdGhlIHBsYW5lX2luZm8/CgpxZW11IHBvbGxzIGluIHJlZ3Vs YXIgaW50ZXJ2YWxzLCBzaW1saWFyIHRvIGhvdyBpdCBjaGVja3MgdGhlIGRpcnR5CmJpdG1hcCBm b3IgdmlkZW8gbWVtb3J5IGluIHJlZ3VsYXIgaW50ZXJ2YWxzIHdpdGggc3RkdmdhLgoKcWVtdSBk aXNwbGF5IHVwZGF0ZSB0aW1lciBydW5zIG9uIDMwZnBzIHVzdWFsbHksIGluIGNhc2Ugbm9ib2R5 IGlzCmxvb2tpbmcgKG5vIHNwaWNlL3ZuYyBjbGllbnQgY29ubmVjdGVkKSBpdCByZWR1Y2VzIHRo ZSB1cGRhdGUgZnJlcXVlbmN5CnRob3VnaC4KCj4gPiBwbGFuZV90eXBlIHNob3VsZCBiZSBEUk1f UExBTkVfVFlQRV9QUklNQVJZIG9yCj4gPiBEUk1fUExBTkVfVFlQRV9DVVJTT1IKPiA+IGZvciBk bWFidWYuCj4gPiAKPiA+IEdpdmVuIHRoYXQgbnZpZGlhIGRvZXNuJ3Qgc3VwcG9ydCBhIHNlcGFy YXRlIGN1cnNvciBwbGFuZSBpbiB0aGVpcgo+ID4gcmVnaW9uIHRoZXkgd291bGQgc3VwcG9ydCBE Uk1fUExBTkVfVFlQRV9QUklNQVJZIG9ubHkuCj4gPiAKPiA+IEkgY2FuJ3Qgc2VlIHlldCB3aGF0 IGlkIHdvdWxkIGJlIHVzZWZ1bCBmb3IuCj4gPiAKPiA+IExpa2V3aXNlIEkgY2FuJ3Qgc2VlIHll dCB3aGF0IHRoZSBWRklPX0dGWF9QTEFORV9GTEFHU18qIGFyZSBnb29kCj4gPiBmb3IuCj4gCj4g SSB0aGluayB3ZSdyZSB0cnlpbmcgdG8gaWRlbnRpZnkgd2hlcmUgdGhpcyBwbGFuZV9pbmZvIGV4 aXN0cy7CoMKgRG9lcwo+IHRoZSB1c2VyIGFzayBmb3IgYSBkbWFidWYgZmQgZm9yIGl0IG9yIHVz ZSBhIHJlZ2lvbi4KCkJ1dCB3aGVuZXZlciBhIHJlZ2lvbiBvciBhIGRtYWJ1ZiBpcyB1c2VkIGlz IGEgZml4ZWQgcHJvcGVydHkgb2YgdGhlCmRldmljZSwgd2h5IGFzc29jaWF0ZSB0aGF0IHdpdGgg YSBwbGFuZT8gIEl0IHdpbGwgYmUgdGhlIHNhbWUgZm9yIGFsbApwbGFuZXMgb2YgYSBkZXZpY2Ug YW55d2F5IC4uLgoKPiBJZiBpdCdzIGEgcmVnaW9uLAo+IHdoaWNoIHJlZ2lvbj8KCk9rLCBpZiB3 ZSB3YW50IHN1cHBvcnQgbXVsdGlwbGUgcmVnaW9ucy4gIERvIHdlPyAgVXNpbmcgdGhlIG9mZnNl dCB3ZQpjYW4gcGxhY2UgbXVsdGlwbGUgcGxhbmVzIGluIGEgc2luZ2xlIHJlZ2lvbi4gIEFuZCBJ J20gbm90IHN1cmUgbnZpZGlhCnBsYW5zIHRvIHVzZSBtdWx0aXBsZSBwbGFuZXMgaW4gdGhlIGZp cnN0IHBsYWNlIC4uLgoKPiA0LiBUd28gaW9jdGwgY29tbWFuZHMKPiA+IFZGSU9fREVWSUNFX1FV RVJZX0dGWF9QTEFORQo+ID4gVkZJT19ERVZJQ0VfR0VUX0ZECj4gCj4gQXJlIHdlIGdvaW5nIHRv IGNvbnNpZGVyIGEgZ2VuZXJpYyBWRklPX0RFVklDRV9RVUVSWSBpb2N0bD/CoMKgQW55Cj4gb3Bp bmlvbnM/wqDCoFRoYW5rcywKCkkgZG9uJ3QgdGhpbmsgYSBnZW5lcmljIGRldmljZSBxdWVyeSBp cyB0aGF0IGhlbHBmdWwuICBEZXBlbmRpbmcgb24gdGhlCmtpbmQgb2YgcXVlcnkgeW91J2xsIGdl dCBiYWNrIGRpZmZlcmVudCBzdHVmZiwgYW5kIHdlIG5lZWQgdG8gaGFuZGxlCnRoYXQgc29tZWhv dywgbGlrZSB0aGlzOgoKdmZpb19kZXZpY2VfcXVlcnkgewogICAgdTMyIGFyZ3N6OwogICAgdTMy IGZsYWdzOwogICAgZW51bSBxdWVyeV90eXBlOyAgLyogb3IgdXNlIGZsYWdzIGZvciB0aGF0ICov CiAgICB1bmlvbiB7CiAgICAgICAgcGxhbmVfaW5mbyBwbGFuZTsKICAgICAgICAvKiB3aGF0ZXZl ciBlbHNlIGNvbWVzIHVwICovCiAgICB9IHF1ZXJ5X3BhcmFtczsKfTsKCkkgZmFpbCB0byBzZWUg aG93IHRoaXMgaXMgZnVuZGFtZW50YWxseSBkaWZmZXJlbnQgZnJvbSBoYXZpbmcgbXVsdGlwbGUK dmZpb19kZXZpY2VfcXVlcnlfKiBzdHJ1Y3RzIChhbmQgaW9jdGxzKS4gIEl0IG9ubHkgcHVzaGVz IHRoZSBwcm9ibGVtCm9uZSBsZXZlbCBkb3duIC4uLgoKT3IgZG8geW91IGhhdmUgc29tZXRoaW5n IGVsc2UgaW4gbWluZD8KCmNoZWVycywKICBHZXJkCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpJbnRlbC1nZnggbWFpbGluZyBsaXN0CkludGVsLWdmeEBs aXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1h 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 S1752850AbdFVIaS (ORCPT ); Thu, 22 Jun 2017 04:30:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38218 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751116AbdFVIaP (ORCPT ); Thu, 22 Jun 2017 04:30:15 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DE4C94025D Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=kraxel@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DE4C94025D Message-ID: <1498120215.25651.5.camel@redhat.com> Subject: Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations From: Gerd Hoffmann To: Alex Williamson Cc: "Zhang, Tina" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , Kirti Wankhede , "Chen, Xiaoguang" , "intel-gvt-dev@lists.freedesktop.org" , "Lv, Zhiyuan" , "Wang, Zhi A" , "Wang, Zhenyu Z" Date: Thu, 22 Jun 2017 10:30:15 +0200 In-Reply-To: <20170621125938.1a92abda@w520.home> References: <1497513611-2814-1-git-send-email-xiaoguang.chen@intel.com> <1497513611-2814-6-git-send-email-xiaoguang.chen@intel.com> <1497542438.29252.1.camel@redhat.com> <20170615143833.7526351b@w520.home> <24c4880b-24f5-ea07-834c-c77d3e895c78@nvidia.com> <1497854312.4207.4.camel@redhat.com> <20170619085530.1f5e46dc@w520.home> <237F54289DF84E4997F34151298ABEBC7C56EBE0@SHSMSX101.ccr.corp.intel.com> <1497956256.16795.7.camel@redhat.com> <20170620090004.44ac7fbc@w520.home> <237F54289DF84E4997F34151298ABEBC7C56F3DC@SHSMSX101.ccr.corp.intel.com> <20170620172204.09405cf4@w520.home> <237F54289DF84E4997F34151298ABEBC7C56F843@SHSMSX101.ccr.corp.intel.com> <1498043011.5802.5.camel@redhat.com> <20170621125938.1a92abda@w520.home> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 22 Jun 2017 08:30:15 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, > > VFIO_DEVICE_FLAGS_GFX_DMABUF? > > After proposing these, I'm kind of questioning their purpose.  In the > case of a GFX region, the user is going to learn that this is > supported > as they parse the region information and find the device specific > region identifying itself as a GFX area.  That needs to happen early > when the user is evaluating the device, so it seems rather redundant > to the flag. Indeed. > If we have dmabuf support, isn't that indicated by trying to query > the > graphics plane_info and getting back a result indicating a dmabuf fd? > Is there any point in time where a device supporting dmabuf fds would > not report this here?  Userspace could really do the same process for > a > graphics region, ie. querying the plane_info, if it exists pursuing > either the region or dmabuf path to get it. Well, you can get a dma-buf only after the guest loaded the driver and initialized the device, so a plane actually exists ... Right now the experimental intel patches throw errors in case no plane exists (yet). Maybe we should have a "bool is_enabled" field in the plane_info struct, so drivers can use that to signal whenever the guest has programmed a valid video mode or not (likewise for the cursor, which doesn't exist with fbcon, only when running xorg). With that in place using the QUERY_PLANE ioctl also for probing looks reasonable. > > generation would be increased each time one of the fields in > > vfio_device_gfx_plane_info changes, typically on mode switches > > (width/height changes) and pageflips (offset changes).  So > > userspace > > can simply compare generation instead of comparing every field to > > figure whenever something changed compared to the previous poll. > > So we have two scenarios, dmabuf and region.  When the user retrieves > a > dmabuf they get plane_info which includes the generation, so they > know > the dmabuf is for that generation.  If they query the plane_info and > get a different generation they should close the previous dmabuf and > get another. Keeping it cached is a valid choice too. > Does this promote the caching idea that a user might > maintain multiple open dmabuf fds and select the appropriate one for > the current device state?  Is it entirely the user's responsibility > to > remember the plane info for an open dmabuf fd? Yes, I'd leave that to userspace. So, when the generation changes userspace knows the guest changed the plane. It could be a configuration the guest has used before (and where userspace could have a cached dma-buf handle for), or it could be something new. > What happens to > existing dmabuf fds when the generation updates, do they stop > refreshing? Depends on what the guest is doing ;) The dma-buf is just a host-side handle for the piece of video memory where the guest stored the framebuffer. > Does it blank the framebuffer? No. > Can the dmabuf fd > transparently update to the new plane_info? No. > The other case is a region, the user queries the plane_info records > the > parameters and region info, and configures access to the region using > that information.  Meanwhile, something changed, plane_info including > generation is updated, but the user is still assuming the previous > plane_info.  How can we avoid such a race? Qemu doesn't. You might get rendering glitches in that case, due to accessing the plane with the wrong configuration. It's fundamentally the same with stdvga btw. > What is the responsibility > of the user and how are they notified to refresh the plane_info? qemu polls in regular intervals, simliar to how it checks the dirty bitmap for video memory in regular intervals with stdvga. qemu display update timer runs on 30fps usually, in case nobody is looking (no spice/vnc client connected) it reduces the update frequency though. > > plane_type should be DRM_PLANE_TYPE_PRIMARY or > > DRM_PLANE_TYPE_CURSOR > > for dmabuf. > > > > Given that nvidia doesn't support a separate cursor plane in their > > region they would support DRM_PLANE_TYPE_PRIMARY only. > > > > I can't see yet what id would be useful for. > > > > Likewise I can't see yet what the VFIO_GFX_PLANE_FLAGS_* are good > > for. > > I think we're trying to identify where this plane_info exists.  Does > the user ask for a dmabuf fd for it or use a region. But whenever a region or a dmabuf is used is a fixed property of the device, why associate that with a plane? It will be the same for all planes of a device anyway ... > If it's a region, > which region? Ok, if we want support multiple regions. Do we? Using the offset we can place multiple planes in a single region. And I'm not sure nvidia plans to use multiple planes in the first place ... > 4. Two ioctl commands > > VFIO_DEVICE_QUERY_GFX_PLANE > > VFIO_DEVICE_GET_FD > > Are we going to consider a generic VFIO_DEVICE_QUERY ioctl?  Any > opinions?  Thanks, I don't think a generic device query is that helpful. Depending on the kind of query you'll get back different stuff, and we need to handle that somehow, like this: vfio_device_query { u32 argsz; u32 flags; enum query_type; /* or use flags for that */ union { plane_info plane; /* whatever else comes up */ } query_params; }; I fail to see how this is fundamentally different from having multiple vfio_device_query_* structs (and ioctls). It only pushes the problem one level down ... Or do you have something else in mind? cheers, Gerd