From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Lee Subject: Re: [RFC PATCH 3/7] vfio: add spimdev support Date: Mon, 6 Aug 2018 09:40:04 +0800 Message-ID: <20180806014004.GF91035@Turing-Arch-b> References: <20180801102221.5308-1-nek.in.cn@gmail.com> <20180801102221.5308-4-nek.in.cn@gmail.com> <20180802034727.GK160746@Turing-Arch-b> <20180802073440.GA91035@Turing-Arch-b> <20180802103528.0b863030.cohuck@redhat.com> <20180802124327.403b10ab@t450s.home> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Zaibo Xu , sanjay.k.kumar-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, Kenneth Lee , Hao Fang , Herbert Xu , Jonathan Corbet , "Tian, Kevin" , linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, Thomas Gleixner , Greg Kroah-Hartman , Cornelia Huck , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Philippe Ombredanne , Kenneth Lee , "David S . Miller" , "linux-accelerators-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" To: Alex Williamson Return-path: Content-Disposition: inline In-Reply-To: <20180802124327.403b10ab-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: linux-crypto.vger.kernel.org T24gVGh1LCBBdWcgMDIsIDIwMTggYXQgMTI6NDM6MjdQTSAtMDYwMCwgQWxleCBXaWxsaWFtc29u IHdyb3RlOgo+IERhdGU6IFRodSwgMiBBdWcgMjAxOCAxMjo0MzoyNyAtMDYwMAo+IEZyb206IEFs ZXggV2lsbGlhbXNvbiA8YWxleC53aWxsaWFtc29uQHJlZGhhdC5jb20+Cj4gVG86IENvcm5lbGlh IEh1Y2sgPGNvaHVja0ByZWRoYXQuY29tPgo+IENDOiBLZW5uZXRoIExlZSA8bGlndW96aHVAaGlz aWxpY29uLmNvbT4sICJUaWFuLCBLZXZpbiIKPiAgPGtldmluLnRpYW5AaW50ZWwuY29tPiwgS2Vu bmV0aCBMZWUgPG5lay5pbi5jbkBnbWFpbC5jb20+LCBKb25hdGhhbiBDb3JiZXQKPiAgPGNvcmJl dEBsd24ubmV0PiwgSGVyYmVydCBYdSA8aGVyYmVydEBnb25kb3IuYXBhbmEub3JnLmF1PiwgIkRh dmlkIFMgLgo+ICBNaWxsZXIiIDxkYXZlbUBkYXZlbWxvZnQubmV0PiwgSm9lcmcgUm9lZGVsIDxq b3JvQDhieXRlcy5vcmc+LCBIYW8gRmFuZwo+ICA8ZmFuZ2hhbzExQGh1YXdlaS5jb20+LCBaaG91 IFdhbmcgPHdhbmd6aG91MUBoaXNpbGljb24uY29tPiwgWmFpYm8gWHUKPiAgPHh1emFpYm9AaHVh d2VpLmNvbT4sIFBoaWxpcHBlIE9tYnJlZGFubmUgPHBvbWJyZWRhbm5lQG5leGIuY29tPiwgIkdy ZWcKPiAgS3JvYWgtSGFydG1hbiIgPGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3JnPiwgVGhvbWFz IEdsZWl4bmVyCj4gIDx0Z2x4QGxpbnV0cm9uaXguZGU+LCAibGludXgtZG9jQHZnZXIua2VybmVs Lm9yZyIKPiAgPGxpbnV4LWRvY0B2Z2VyLmtlcm5lbC5vcmc+LCAibGludXgta2VybmVsQHZnZXIu a2VybmVsLm9yZyIKPiAgPGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc+LCAibGludXgtY3J5 cHRvQHZnZXIua2VybmVsLm9yZyIKPiAgPGxpbnV4LWNyeXB0b0B2Z2VyLmtlcm5lbC5vcmc+LCAi aW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmciCj4gIDxpb21tdUBsaXN0cy5saW51eC1m b3VuZGF0aW9uLm9yZz4sICJrdm1Admdlci5rZXJuZWwub3JnIgo+ICA8a3ZtQHZnZXIua2VybmVs Lm9yZz4sICJsaW51eC1hY2NlbGVyYXRvcnNAbGlzdHMub3psYWJzLm9yZ1wiCj4gICAgICAgICAg PGxpbnV4LWFjY2VsZXJhdG9yc0BsaXN0cy5vemxhYnMub3JnPiwgTHUgQmFvbHUKPiAgPGJhb2x1 Lmx1QGxpbnV4LmludGVsLmNvbT4sICBLdW1hciIsIDxTYW5qYXkgSyAiCj4gIDxzYW5qYXkuay5r dW1hckBpbnRlbC5jb20+LCAiIGxpbnV4YXJtQGh1YXdlaS5jb20gIgo+ICA8bGludXhhcm1AaHVh d2VpLmNvbT4iPgo+IFN1YmplY3Q6IFJlOiBbUkZDIFBBVENIIDMvN10gdmZpbzogYWRkIHNwaW1k ZXYgc3VwcG9ydAo+IE1lc3NhZ2UtSUQ6IDwyMDE4MDgwMjEyNDMyNy40MDNiMTBhYkB0NDUwcy5o b21lPgo+IAo+IE9uIFRodSwgMiBBdWcgMjAxOCAxMDozNToyOCArMDIwMAo+IENvcm5lbGlhIEh1 Y2sgPGNvaHVja0ByZWRoYXQuY29tPiB3cm90ZToKPiAKPiA+IE9uIFRodSwgMiBBdWcgMjAxOCAx NTozNDo0MCArMDgwMAo+ID4gS2VubmV0aCBMZWUgPGxpZ3Vvemh1QGhpc2lsaWNvbi5jb20+IHdy b3RlOgo+ID4gCj4gPiA+IE9uIFRodSwgQXVnIDAyLCAyMDE4IGF0IDA0OjI0OjIyQU0gKzAwMDAs IFRpYW4sIEtldmluIHdyb3RlOiAgCj4gPiAKPiA+ID4gPiA+IEZyb206IEtlbm5ldGggTGVlIFtt YWlsdG86bGlndW96aHVAaGlzaWxpY29uLmNvbV0KPiA+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBB dWd1c3QgMiwgMjAxOCAxMTo0NyBBTQo+ID4gPiA+ID4gICAgIAo+ID4gPiA+ID4gPiAgICAKPiA+ ID4gPiA+ID4gPiBGcm9tOiBLZW5uZXRoIExlZQo+ID4gPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2Rh eSwgQXVndXN0IDEsIDIwMTggNjoyMiBQTQo+ID4gPiA+ID4gPiA+Cj4gPiA+ID4gPiA+ID4gRnJv bTogS2VubmV0aCBMZWUgPGxpZ3Vvemh1QGhpc2lsaWNvbi5jb20+Cj4gPiA+ID4gPiA+ID4KPiA+ ID4gPiA+ID4gPiBTUElNREVWIGlzICJTaGFyZSBQYXJlbnQgSU9NTVUgTWRldiIuIEl0IGlzIGEg dmZpby1tZGV2LiBCdXQgZGlmZmVyICAgIAo+ID4gPiA+ID4gZnJvbSAgICAKPiA+ID4gPiA+ID4g PiB0aGUgZ2VuZXJhbCB2ZmlvLW1kZXY6Cj4gPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gPiAxLiBJ dCBzaGFyZXMgaXRzIHBhcmVudCdzIElPTU1VLgo+ID4gPiA+ID4gPiA+IDIuIFRoZXJlIGlzIG5v IGhhcmR3YXJlIHJlc291cmNlIGF0dGFjaGVkIHRvIHRoZSBtZGV2IGlzIGNyZWF0ZWQuIFRoZQo+ ID4gPiA+ID4gPiA+IGhhcmR3YXJlIHJlc291cmNlIChBIGBxdWV1ZScpIGlzIGFsbG9jYXRlZCBv bmx5IHdoZW4gdGhlIG1kZXYgaXMKPiA+ID4gPiA+ID4gPiBvcGVuZWQuICAgIAo+ID4gPiA+ID4g Pgo+ID4gPiA+ID4gPiBBbGV4IGhhcyBjb25jZXJuIG9uIGRvaW5nIHNvLCBhcyBwb2ludGVkIG91 dCBpbjoKPiA+ID4gPiA+ID4KPiA+ID4gPiA+ID4gCWh0dHBzOi8vd3d3LnNwaW5pY3MubmV0L2xp c3RzL2t2bS9tc2cxNzI2NTIuaHRtbAo+ID4gPiA+ID4gPgo+ID4gPiA+ID4gPiByZXNvdXJjZSBh bGxvY2F0aW9uIHNob3VsZCBiZSByZXNlcnZlZCBhdCBjcmVhdGlvbiB0aW1lLiAgICAKPiA+ID4g PiA+IAo+ID4gPiA+ID4gWWVzLiBUaGF0IGlzIHdoeSBJIGtlZXAgdGVsbGluZyB0aGF0IFNQSU1E RVYgaXMgbm90IGZvciAiVk0iLCBpdCBpcyBmb3IgIm1hbnkKPiA+ID4gPiA+IHByb2Nlc3NlcyIs IGl0IGlzIGp1c3QgYW4gYWNjZXNzIHBvaW50IHRvIHRoZSBwcm9jZXNzLiBOb3QgYSBkZXZpY2Ug dG8gVk0uIEkKPiA+ID4gPiA+IGhvcGUKPiA+ID4gPiA+IEFsZXggY2FuIGFjY2VwdCBpdDopCj4g PiA+ID4gPiAgICAgCj4gPiA+ID4gCj4gPiA+ID4gVkZJTyBpcyBqdXN0IGFib3V0IGFzc2lnbmlu ZyBkZXZpY2UgcmVzb3VyY2UgdG8gdXNlciBzcGFjZS4gSXQgZG9lc24ndCBjYXJlCj4gPiA+ID4g d2hldGhlciBpdCdzIG5hdGl2ZSBwcm9jZXNzZXMgb3IgVk0gdXNpbmcgdGhlIGRldmljZSBzbyBm YXIuIEFsb25nIHRoZSBkaXJlY3Rpb24KPiA+ID4gPiB3aGljaCB5b3UgZGVzY3JpYmVkLCBsb29r cyBWRklPIG5lZWRzIHRvIHN1cHBvcnQgdGhlIGNvbmZpZ3VyYXRpb24gdGhhdAo+ID4gPiA+IHNv bWUgbWRldnMgYXJlIHVzZWQgZm9yIG5hdGl2ZSBwcm9jZXNzIG9ubHksIHdoaWxlIG90aGVycyBj YW4gYmUgdXNlZAo+ID4gPiA+IGZvciBib3RoIG5hdGl2ZSBhbmQgVk0uIEknbSBub3Qgc3VyZSB3 aGV0aGVyIHRoZXJlIGlzIGEgY2xlYW4gd2F5IHRvCj4gPiA+ID4gZW5mb3JjZSBpdC4uLiAgICAK PiA+ID4gCj4gPiA+IEkgaGFkIHRoZSBzYW1lIGlkZWEgYXQgdGhlIGJlZ2lubmluZy4gQnV0IGZp bmFsbHkgSSBmb3VuZCB0aGF0IHRoZSBsaWZlIGN5Y2xlCj4gPiA+IG9mIHRoZSB2aXJ0dWFsIGRl dmljZSBmb3IgVk0gYW5kIHByb2Nlc3Mgd2VyZSBkaWZmZXJlbnQuIENvbnNpZGVyIHlvdSBjcmVh dGUKPiA+ID4gc29tZSBtZGV2cyBmb3IgVk0gdXNlLCB5b3Ugd2lsbCBnaXZlIGFsbCB0aG9zZSBt ZGV2cyB0byBsaWItdmlydCwgd2hpY2gKPiA+ID4gZGlzdHJpYnV0ZSB0aG9zZSBtZGV2IHRvIFZN cyBvciBjb250YWluZXJzLiBJZiB0aGUgVk0gb3IgY29udGFpbmVyIGV4aXRzLCB0aGUKPiA+ID4g bWRldiBpcyByZXR1cm5lZCB0byB0aGUgbGliLXZpcnQgYW5kIHVzZWQgZm9yIG5leHQgYWxsb2Nh dGlvbi4gSXQgaXMgdGhlCj4gPiA+IGFkbWluaXN0cmF0b3Igd2hvIGNvbnRyb2xsZWQgZXZlcnkg bWRldidzIGFsbG9jYXRpb24uCj4gCj4gTGlidmlydCBjdXJyZW50bHkgZG9lcyBubyBtYW5hZ2Vt ZW50IG9mIG1kZXYgZGV2aWNlcywgc28gSSBiZWxpZXZlCj4gdGhpcyBleGFtcGxlIGlzIGZpY3Rp dGlvdXMuICBUaGUgZXh0ZW50IG9mIGxpYnZpcnQncyBpbnRlcmFjdGlvbiB3aXRoCj4gbWRldiBp cyB0aGF0IFhNTCBtYXkgc3BlY2lmeSBhbiBtZGV2IFVVSUQgYXMgdGhlIHNvdXJjZSBmb3IgYSBo b3N0ZGV2Cj4gYW5kIHNldCB0aGUgcGVybWlzc2lvbnMgb24gdGhlIGRldmljZSBmaWxlcyBhcHBy b3ByaWF0ZWx5LiAgV2hldGhlcgo+IG1kZXZzIGFyZSBjcmVhdGVkIGluIGFkdmFuY2UgYW5kIHJl LXVzZWQgb3IgY3JlYXRlZCBhbmQgZGVzdHJveWVkCj4gYXJvdW5kIGEgVk0gaW5zdGFuY2UgKGZv ciBleGFtcGxlIHZpYSBxZW11IGhvb2tzIHNjcmlwdHMpIGlzIG5vdCBhCj4gcG9saWN5IHRoYXQg bGlidmlydCBpbXBvc2VzLgo+ICAKPiA+ID4gQnV0IGZvciBwcm9jZXNzLCBpdCBpcyBkaWZmZXJl bnQuIFRoZXJlIGlzIG5vIGxpYi12aXJ0IGluIGNvbnRyb2wuIFRoZQo+ID4gPiBhZG1pbmlzdHJh dG9yJ3MgaW50ZW5zaW9uIGlzIHRvIGdyYW50IHNvbWUgdHlwZSBvZiBhcHBsaWNhdGlvbiB0byBh Y2Nlc3MgdGhlCj4gPiA+IGhhcmR3YXJlLiBUaGUgYXBwbGljYXRpb24gY2FuIGdldCBhIGhhbmRs ZSBvZiB0aGUgaGFyZHdhcmUsIHNlbmQgcmVxdWVzdCBhbmQgZ2V0Cj4gPiA+IHRoZSByZXN1bHQu IFRoYXQncyBhbGwuIEhlL1NoZSBkb3NlIG5vdCBjYXJlIHdoaWNoIG1kZXYgaXMgYWxsb2NhdGVk IHRvIHRoYXQKPiA+ID4gYXBwbGljYXRpb24uIElmIGl0IGNyYXNoZXMsIGl0IHNob3VsZCBiZSB0 aGUga2VybmVsJ3MgcmVzcG9uc2liaWxpdHkgdG8gd2l0aGRyYXcKPiA+ID4gdGhlIHJlc291cmNl LCB0aGUgc3lzdGVtIGFkbWluaXN0cmF0b3IgZG9lcyBub3Qgd2FudCB0byBkbyBpdCBieSBoYW5k LiAgCj4gCj4gTGlidmlydCBpcyBhbHNvIG5vdCBhIHJlcXVpcmVkIGNvbXBvbmVudCBmb3IgVk0g bGlmZWN5Y2xlcywgaXQncyBhbgo+IG9wdGlvbmFsIG1hbmFnZW1lbnQgaW50ZXJmYWNlLCBidXQg dGhlcmUgYXJlIGFsc28gVk0gbGlmZWN5Y2xlcyBleGFjdGx5Cj4gYXMgeW91IGRlc2NyaWJlLiAg QSBWTSBtYXkgd2FudCBhIGdpdmVuIHR5cGUgb2YgdkdQVSwgdGhlcmUgbWlnaHQgYmUKPiBtdWx0 aXBsZSBzb3VyY2VzIG9mIHRoYXQgdHlwZSBhbmQgYW55IGluc3RhbmNlIGlzIGZ1bmdpYmxlIHRv IGFueQo+IG90aGVyLiAgU3VjaCBhbiBtZGV2IGNhbiBiZSBkeW5hbWljYWxseSBjcmVhdGVkLCBh c3NpZ25lZCB0byB0aGUgVk0sCj4gYW5kIGRlc3Ryb3llZCBsYXRlci4gIFdoeSBkbyB3ZSBuZWVk IHRvIHN1cHBvcnQgImVtcHR5IiBtZGV2cyB0aGF0IGRvCj4gbm90IHJlc2VydmUgcmVzZXJ2ZSBy ZXNvdXJjZXMgdW50aWwgb3BlbmVkPyAgVGhlIGNvbmNlcHQgb2YgYXZhaWxhYmxlCj4gaW5zdGFu Y2VzIGlzIGVudGlyZWx5IGxvc3Qgd2l0aCB0aGF0IGFwcHJvYWNoIGFuZCBpdCBjcmVhdGVzIGFu Cj4gZW52aXJvbm1lbnQgdGhhdCdzIGRpZmZpY3VsdCB0byBzdXBwb3J0LCByZXNvdXJjZXMgbWF5 IG5vdCBiZSBhdmFpbGFibGUKPiBhdCB0aGUgdGltZSB0aGUgdXNlciBhdHRlbXB0cyB0byBhY2Nl c3MgdGhlbS4KPiAgCj4gPiBJIGRvbid0IHRoaW5rIHRoYXQgeW91IHNob3VsZCBkaXN0aW5ndWlz aCB0aGUgY2FzZXMgYnkgdGhlIHByZXNlbmNlIG9mCj4gPiBhIG1hbmFnZW1lbnQgYXBwbGljYXRp b24uIEhvdyBjYW4gdGhlIG1kZXYgZHJpdmVyIGtub3cgd2hhdCB0aGUKPiA+IGludGVudGlvbiBi ZWhpbmQgdXNpbmcgdGhlIGRldmljZSBpcz8KPiAKPiBBYnNvbHV0ZWx5LCB2ZmlvIGlzIGEgdXNl cnNwYWNlIGRyaXZlciBpbnRlcmZhY2UsIGl0J3Mgbm90IHRhaWxvcmVkIHRvCj4gVk0gdXNhZ2Ug YW5kIHdlIGNhbm5vdCBrbm93IHRoZSBpbnRlbnRpb25zIG9mIHRoZSB1c2VyLgo+ICAKPiA+IFdv dWxkIGl0IG1ha2UgbW9yZSBzZW5zZSB0byB1c2UgYSBkaWZmZXJlbnQgbWVjaGFuaXNtIHRvIGVu Zm9yY2UgdGhhdAo+ID4gYXBwbGljYXRpb25zIG9ubHkgdXNlIHRob3NlIGhhbmRsZXMgdGhleSBh cmUgc3VwcG9zZWQgdG8gdXNlPyBNYXliZQo+ID4gY2dyb3Vwcz8gSSBkb24ndCB0aGluayBpdCdz IGEgZ29vZCBpZGVhIHRvIHB1c2ggdXNhZ2UgcG9saWN5IGludG8gdGhlCj4gPiBrZXJuZWwuCj4g Cj4gSSBhZ3JlZSwgdGhpcyBzb3VuZHMgbGlrZSBhIHVzZXJzcGFjZSBwcm9ibGVtLCBtZGV2IHN1 cHBvcnRzIGR5bmFtaWMKPiBjcmVhdGlvbiBhbmQgcmVtb3ZhbCBvZiBtZGV2IGRldmljZXMsIGlm IHRoZXJlJ3MgYW4gaXNzdWUgd2l0aAo+IG1haW50YWluaW5nIGEgc2V0IG9mIHN0YW5kYnkgZGV2 aWNlcyB0aGF0IGEgdXNlciBoYXMgYWNjZXNzIHRvLCB0aGlzCj4gc291bmRzIGxpa2UgYSB1c2Vy c3BhY2UgYnJva2VyIHByb2JsZW0uICBJdCBtYWtlcyBtb3JlIHNlbnNlIHRvIG1lIHRvCj4gaGF2 ZSBhIG1vZGVsIHdoZXJlIGEgdXNlcnNwYWNlIGFwcGxpY2F0aW9uIGNhbiBtYWtlIGEgcmVxdWVz dCB0byBhCj4gYnJva2VyIGFuZCB0aGUgYnJva2VyIGNhbiByZXBseSB3aXRoICJub25lIGF2YWls YWJsZSIgcmF0aGVyIHRoYW4KPiBoYXZpbmcgYSBzZXQgb2YgZGV2aWNlcyBvbiBzdGFuZGJ5IHRo YXQgbWF5IG9yIG1heSBub3Qgd29yayBkZXBlbmRpbmcKPiBvbiB0aGUgc3lzdGVtIGxvYWQgYW5k IG90aGVyIHVzZXJzLiAgVGhhbmtzLAo+IAo+IEFsZXgKCkkgYW0gc29ycnksIEkgdXNlZCBhIHdy b25nIG11dHQgY29tbWFuZCB3aGVuIHJlcGx5IHRvIENvcm5lbGlhJ3MgbGFzdCBtYWlsLiBUaGUK bGFzdCByZXBseSBkb3NlIG5vdCBzdGF5IHdpdGhpbiB0aGlzIHRocmVhZC4gU28gcGxlYXNlIGxl dCBtZSByZXBlYXQgbXkgcG9pbnQKaGVyZS4KCkkgc2hvdWxkIG5vdCBoYXZlIHVzZSBsaWJ2aXJ0 IGFzIHRoZSBleGFtcGxlLiBCdXQgV2FycERyaXZlIHdvcmtzIGluIHN1Y2gKc2NlbmFyaW86Cgox LiBJdCBzdXBwb3J0cyB0aG91c2FuZHMgb2YgcHJvY2Vzc2VzLiBUYWtlIHppcCBhY2NlbGVyYXRv ciBhcyBhbiBleGFtcGxlLCBhbnkKYXBwbGljYXRpb24gbmVlZCBkYXRhIGNvbXByZXNzaW9uL2Rl Y29tcHJlc3Npb24gd2lsbCBuZWVkIHRvIGludGVyYWN0IHdpdGggdGhlCmFjY2VsZXJhdG9yLiBU byBzdXBwb3J0IHRoYXQsIHlvdSBoYXZlIHRvIGNyZWF0ZSB0ZW5zIG9mIHRob3VzYW5kcyBvZiBt ZGV2IGZvcgp0aGVpciB1c2FnZS4gSSBkb24ndCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byBo YXZlIHNvIG1hbnkgZGV2aWNlcyBpbiB0aGUKc3lzdGVtLgoKMi4gVGhlIGFwcGxpY2F0aW9uIGRv ZXMgbm90IHdhbnQgdG8gb3duIHRoZSBtZGV2IGZvciBsb25nLiBJdCBqdXN0IG5lZWQgYW4KYWNj ZXNzIHBvaW50IGZvciB0aGUgaGFyZHdhcmUgc2VydmljZS4gSWYgaXQgaGFzIHRvIGludGVyYWN0 IHdpdGggYW4gbWFuYWdlbWVudAphZ2VudCBmb3IgYWxsb2NhdGlvbiBhbmQgcmVsZWFzZSwgdGhp cyBtYWtlcyB0aGUgcHJvYmxlbSBjb21wbGV4LgoKMy4gVGhlIHNlcnZpY2UgaXMgYm91bmQgd2l0 aCB0aGUgcHJvY2Vzcy4gV2hlbiB0aGUgcHJvY2VzcyBleGl0LCB0aGUgcmVzb3VyY2UKc2hvdWxk IGJlIHJlbGVhc2VkIGF1dG9tYXRpY2FsbHkuIEtlcm5lbCBpcyB0aGUgYmVzdCBwbGFjZSB0byBt b25pdG9yIHRoZSBzdGF0ZQpvZiB0aGUgcHJvY2Vzcy4KCkkgYWdyZWUgdGhpcyBleHRlbmRpbmcg dGhlIGNvbmNlcHQgb2YgbWRldi4gQnV0IGFnYWluLCBpdCBpcyBjbGVhbmVyIHRoYW4KY3JlYXRp bmcgYW5vdGhlciBmYWNpbGl0eSBmb3IgdXNlciBsYW5kIERNQS4gV2UganVzdCBuZWVkIHRvIHRh a2UgbWRldiBhcyBhbgphY2Nlc3MgcG9pbnQgb2YgdGhlIGRldmljZTogd2hlbiBpdCBpcyBvcGVu LCB0aGUgcmVzb3VyY2UgaXMgZ2l2ZW4uIEl0IGlzIG5vdCBhCmRldmljZSBmb3IgYSBwYXJ0aWN1 bGFyIGVudGl0eSBvciBpbnN0YW5jZS4gQnV0IGl0IGlzIHN0aWxsIGEgZGV2aWNlIHdoaWNoIGNh bgpwcm92aWRlIHNlcnZpY2Ugb2YgdGhlIGhhcmR3YXJlLgoKQ29ybmVsaWEgaXMgd29ycnlpbmcg YWJvdXQgcmVzb3VyY2Ugc3RhcnZpbmcuIEkgdGhpbmsgdGhhdCBjYW4gYmUgc29sdmVkIGJ5IHNl dApyZXN0cmljdGlvbiBvbiB0aGUgbWRldiBpdHNlbGYuIE1kZXYgbWFuYWdlbWVudCBhZ2VudCBk b3NlIG5vdCBoZWxwIG11Y2ggaGVyZS4KTWFuYWdlbWVudCBvbiB0aGUgbWRldiBpdHNlbGYgY2Fu IHN0aWxsIGxlYWQgdG8gdGhlIHN0YXR1cyBvZiBydW5uaW5nIG91dCBvZgpyZXNvdXJjZS4KClRo YW5rcwoKCi0tIAoJCQktS2VubmV0aChIaXNpbGljb24pCgo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQrmnKzpgq7ku7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/v vIzku4XpmZDkuo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTn u4TjgILnpoEK5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/55So77yI5YyF5ous 5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi244CB5oiW5pWj5Y+R 77yJ5pys6YKu5Lu25LitCueahOS/oeaBr+OAguWmguaenOaCqOmUmeaUtuS6huacrOmCruS7tu+8 jOivt+aCqOeri+WNs+eUteivneaIlumCruS7tumAmuefpeWPkeS7tuS6uuW5tuWIoOmZpOacrOmC ruS7tu+8gQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50 aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLAp3aGljaCBpcyBpbnRlbmRlZCBvbmx5IGZvciB0 aGUgcGVyc29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4KQW55IHVz ZSBvZiB0aGUgCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVk aW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yCnBhcnRpYWwgZGlzY2xvc3VyZSwgcmVw cm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlCmlu dGVuZGVkIApyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBl LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkKdGhlIHNlbmRlciBieSBwaG9uZSBvciBlbWFp bCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KaW9tbXUgbWFpbGluZyBsaXN0CmlvbW11QGxpc3RzLmxpbnV4 LWZvdW5kYXRpb24ub3JnCmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9uLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lvbW11 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 2C0467E3B8 for ; Mon, 6 Aug 2018 01:41:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726971AbeHFDsS (ORCPT ); Sun, 5 Aug 2018 23:48:18 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:49570 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726834AbeHFDsS (ORCPT ); Sun, 5 Aug 2018 23:48:18 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 48E82887AA216; Mon, 6 Aug 2018 09:41:33 +0800 (CST) Received: from localhost (10.67.212.75) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 6 Aug 2018 09:41:26 +0800 Date: Mon, 6 Aug 2018 09:40:04 +0800 From: Kenneth Lee To: Alex Williamson CC: Kenneth Lee , "Tian, Kevin" , Kenneth Lee , Jonathan Corbet , Herbert Xu , "David S . Miller" , Joerg Roedel , Hao Fang , Zhou Wang , Zaibo Xu , Philippe Ombredanne , "Greg Kroah-Hartman" , Thomas Gleixner , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "linux-accelerators@lists.ozlabs.org" , Lu Baolu , , , Cornelia Huck Subject: Re: [RFC PATCH 3/7] vfio: add spimdev support Message-ID: <20180806014004.GF91035@Turing-Arch-b> References: <20180801102221.5308-1-nek.in.cn@gmail.com> <20180801102221.5308-4-nek.in.cn@gmail.com> <20180802034727.GK160746@Turing-Arch-b> <20180802073440.GA91035@Turing-Arch-b> <20180802103528.0b863030.cohuck@redhat.com> <20180802124327.403b10ab@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180802124327.403b10ab@t450s.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Thu, Aug 02, 2018 at 12:43:27PM -0600, Alex Williamson wrote: > Date: Thu, 2 Aug 2018 12:43:27 -0600 > From: Alex Williamson > To: Cornelia Huck > CC: Kenneth Lee , "Tian, Kevin" > , Kenneth Lee , Jonathan Corbet > , Herbert Xu , "David S . > Miller" , Joerg Roedel , Hao Fang > , Zhou Wang , Zaibo Xu > , Philippe Ombredanne , "Greg > Kroah-Hartman" , Thomas Gleixner > , "linux-doc@vger.kernel.org" > , "linux-kernel@vger.kernel.org" > , "linux-crypto@vger.kernel.org" > , "iommu@lists.linux-foundation.org" > , "kvm@vger.kernel.org" > , "linux-accelerators@lists.ozlabs.org\" > , Lu Baolu > , Kumar", , " linuxarm@huawei.com " > "> > Subject: Re: [RFC PATCH 3/7] vfio: add spimdev support > Message-ID: <20180802124327.403b10ab@t450s.home> > > On Thu, 2 Aug 2018 10:35:28 +0200 > Cornelia Huck wrote: > > > On Thu, 2 Aug 2018 15:34:40 +0800 > > Kenneth Lee wrote: > > > > > On Thu, Aug 02, 2018 at 04:24:22AM +0000, Tian, Kevin wrote: > > > > > > > From: Kenneth Lee [mailto:liguozhu@hisilicon.com] > > > > > Sent: Thursday, August 2, 2018 11:47 AM > > > > > > > > > > > > > > > > > > From: Kenneth Lee > > > > > > > Sent: Wednesday, August 1, 2018 6:22 PM > > > > > > > > > > > > > > From: Kenneth Lee > > > > > > > > > > > > > > SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ > > > > > from > > > > > > > the general vfio-mdev: > > > > > > > > > > > > > > 1. It shares its parent's IOMMU. > > > > > > > 2. There is no hardware resource attached to the mdev is created. The > > > > > > > hardware resource (A `queue') is allocated only when the mdev is > > > > > > > opened. > > > > > > > > > > > > Alex has concern on doing so, as pointed out in: > > > > > > > > > > > > https://www.spinics.net/lists/kvm/msg172652.html > > > > > > > > > > > > resource allocation should be reserved at creation time. > > > > > > > > > > Yes. That is why I keep telling that SPIMDEV is not for "VM", it is for "many > > > > > processes", it is just an access point to the process. Not a device to VM. I > > > > > hope > > > > > Alex can accept it:) > > > > > > > > > > > > > VFIO is just about assigning device resource to user space. It doesn't care > > > > whether it's native processes or VM using the device so far. Along the direction > > > > which you described, looks VFIO needs to support the configuration that > > > > some mdevs are used for native process only, while others can be used > > > > for both native and VM. I'm not sure whether there is a clean way to > > > > enforce it... > > > > > > I had the same idea at the beginning. But finally I found that the life cycle > > > of the virtual device for VM and process were different. Consider you create > > > some mdevs for VM use, you will give all those mdevs to lib-virt, which > > > distribute those mdev to VMs or containers. If the VM or container exits, the > > > mdev is returned to the lib-virt and used for next allocation. It is the > > > administrator who controlled every mdev's allocation. > > Libvirt currently does no management of mdev devices, so I believe > this example is fictitious. The extent of libvirt's interaction with > mdev is that XML may specify an mdev UUID as the source for a hostdev > and set the permissions on the device files appropriately. Whether > mdevs are created in advance and re-used or created and destroyed > around a VM instance (for example via qemu hooks scripts) is not a > policy that libvirt imposes. > > > > But for process, it is different. There is no lib-virt in control. The > > > administrator's intension is to grant some type of application to access the > > > hardware. The application can get a handle of the hardware, send request and get > > > the result. That's all. He/She dose not care which mdev is allocated to that > > > application. If it crashes, it should be the kernel's responsibility to withdraw > > > the resource, the system administrator does not want to do it by hand. > > Libvirt is also not a required component for VM lifecycles, it's an > optional management interface, but there are also VM lifecycles exactly > as you describe. A VM may want a given type of vGPU, there might be > multiple sources of that type and any instance is fungible to any > other. Such an mdev can be dynamically created, assigned to the VM, > and destroyed later. Why do we need to support "empty" mdevs that do > not reserve reserve resources until opened? The concept of available > instances is entirely lost with that approach and it creates an > environment that's difficult to support, resources may not be available > at the time the user attempts to access them. > > > I don't think that you should distinguish the cases by the presence of > > a management application. How can the mdev driver know what the > > intention behind using the device is? > > Absolutely, vfio is a userspace driver interface, it's not tailored to > VM usage and we cannot know the intentions of the user. > > > Would it make more sense to use a different mechanism to enforce that > > applications only use those handles they are supposed to use? Maybe > > cgroups? I don't think it's a good idea to push usage policy into the > > kernel. > > I agree, this sounds like a userspace problem, mdev supports dynamic > creation and removal of mdev devices, if there's an issue with > maintaining a set of standby devices that a user has access to, this > sounds like a userspace broker problem. It makes more sense to me to > have a model where a userspace application can make a request to a > broker and the broker can reply with "none available" rather than > having a set of devices on standby that may or may not work depending > on the system load and other users. Thanks, > > Alex I am sorry, I used a wrong mutt command when reply to Cornelia's last mail. The last reply dose not stay within this thread. So please let me repeat my point here. I should not have use libvirt as the example. But WarpDrive works in such scenario: 1. It supports thousands of processes. Take zip accelerator as an example, any application need data compression/decompression will need to interact with the accelerator. To support that, you have to create tens of thousands of mdev for their usage. I don't think it is a good idea to have so many devices in the system. 2. The application does not want to own the mdev for long. It just need an access point for the hardware service. If it has to interact with an management agent for allocation and release, this makes the problem complex. 3. The service is bound with the process. When the process exit, the resource should be released automatically. Kernel is the best place to monitor the state of the process. I agree this extending the concept of mdev. But again, it is cleaner than creating another facility for user land DMA. We just need to take mdev as an access point of the device: when it is open, the resource is given. It is not a device for a particular entity or instance. But it is still a device which can provide service of the hardware. Cornelia is worrying about resource starving. I think that can be solved by set restriction on the mdev itself. Mdev management agent dose not help much here. Management on the mdev itself can still lead to the status of running out of resource. Thanks -- -Kenneth(Hisilicon) ================================================================================ 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07B0BC46471 for ; Mon, 6 Aug 2018 01:41:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9D7972192C for ; Mon, 6 Aug 2018 01:41:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D7972192C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hisilicon.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727350AbeHFDsS (ORCPT ); Sun, 5 Aug 2018 23:48:18 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:49570 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726834AbeHFDsS (ORCPT ); Sun, 5 Aug 2018 23:48:18 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 48E82887AA216; Mon, 6 Aug 2018 09:41:33 +0800 (CST) Received: from localhost (10.67.212.75) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 6 Aug 2018 09:41:26 +0800 Date: Mon, 6 Aug 2018 09:40:04 +0800 From: Kenneth Lee To: Alex Williamson CC: Kenneth Lee , "Tian, Kevin" , Kenneth Lee , Jonathan Corbet , Herbert Xu , "David S . Miller" , Joerg Roedel , Hao Fang , Zhou Wang , Zaibo Xu , Philippe Ombredanne , "Greg Kroah-Hartman" , Thomas Gleixner , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-crypto@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "linux-accelerators@lists.ozlabs.org" , Lu Baolu , , , Cornelia Huck Subject: Re: [RFC PATCH 3/7] vfio: add spimdev support Message-ID: <20180806014004.GF91035@Turing-Arch-b> References: <20180801102221.5308-1-nek.in.cn@gmail.com> <20180801102221.5308-4-nek.in.cn@gmail.com> <20180802034727.GK160746@Turing-Arch-b> <20180802073440.GA91035@Turing-Arch-b> <20180802103528.0b863030.cohuck@redhat.com> <20180802124327.403b10ab@t450s.home> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180802124327.403b10ab@t450s.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 02, 2018 at 12:43:27PM -0600, Alex Williamson wrote: > Date: Thu, 2 Aug 2018 12:43:27 -0600 > From: Alex Williamson > To: Cornelia Huck > CC: Kenneth Lee , "Tian, Kevin" > , Kenneth Lee , Jonathan Corbet > , Herbert Xu , "David S . > Miller" , Joerg Roedel , Hao Fang > , Zhou Wang , Zaibo Xu > , Philippe Ombredanne , "Greg > Kroah-Hartman" , Thomas Gleixner > , "linux-doc@vger.kernel.org" > , "linux-kernel@vger.kernel.org" > , "linux-crypto@vger.kernel.org" > , "iommu@lists.linux-foundation.org" > , "kvm@vger.kernel.org" > , "linux-accelerators@lists.ozlabs.org\" > , Lu Baolu > , Kumar", , " linuxarm@huawei.com " > "> > Subject: Re: [RFC PATCH 3/7] vfio: add spimdev support > Message-ID: <20180802124327.403b10ab@t450s.home> > > On Thu, 2 Aug 2018 10:35:28 +0200 > Cornelia Huck wrote: > > > On Thu, 2 Aug 2018 15:34:40 +0800 > > Kenneth Lee wrote: > > > > > On Thu, Aug 02, 2018 at 04:24:22AM +0000, Tian, Kevin wrote: > > > > > > > From: Kenneth Lee [mailto:liguozhu@hisilicon.com] > > > > > Sent: Thursday, August 2, 2018 11:47 AM > > > > > > > > > > > > > > > > > > From: Kenneth Lee > > > > > > > Sent: Wednesday, August 1, 2018 6:22 PM > > > > > > > > > > > > > > From: Kenneth Lee > > > > > > > > > > > > > > SPIMDEV is "Share Parent IOMMU Mdev". It is a vfio-mdev. But differ > > > > > from > > > > > > > the general vfio-mdev: > > > > > > > > > > > > > > 1. It shares its parent's IOMMU. > > > > > > > 2. There is no hardware resource attached to the mdev is created. The > > > > > > > hardware resource (A `queue') is allocated only when the mdev is > > > > > > > opened. > > > > > > > > > > > > Alex has concern on doing so, as pointed out in: > > > > > > > > > > > > https://www.spinics.net/lists/kvm/msg172652.html > > > > > > > > > > > > resource allocation should be reserved at creation time. > > > > > > > > > > Yes. That is why I keep telling that SPIMDEV is not for "VM", it is for "many > > > > > processes", it is just an access point to the process. Not a device to VM. I > > > > > hope > > > > > Alex can accept it:) > > > > > > > > > > > > > VFIO is just about assigning device resource to user space. It doesn't care > > > > whether it's native processes or VM using the device so far. Along the direction > > > > which you described, looks VFIO needs to support the configuration that > > > > some mdevs are used for native process only, while others can be used > > > > for both native and VM. I'm not sure whether there is a clean way to > > > > enforce it... > > > > > > I had the same idea at the beginning. But finally I found that the life cycle > > > of the virtual device for VM and process were different. Consider you create > > > some mdevs for VM use, you will give all those mdevs to lib-virt, which > > > distribute those mdev to VMs or containers. If the VM or container exits, the > > > mdev is returned to the lib-virt and used for next allocation. It is the > > > administrator who controlled every mdev's allocation. > > Libvirt currently does no management of mdev devices, so I believe > this example is fictitious. The extent of libvirt's interaction with > mdev is that XML may specify an mdev UUID as the source for a hostdev > and set the permissions on the device files appropriately. Whether > mdevs are created in advance and re-used or created and destroyed > around a VM instance (for example via qemu hooks scripts) is not a > policy that libvirt imposes. > > > > But for process, it is different. There is no lib-virt in control. The > > > administrator's intension is to grant some type of application to access the > > > hardware. The application can get a handle of the hardware, send request and get > > > the result. That's all. He/She dose not care which mdev is allocated to that > > > application. If it crashes, it should be the kernel's responsibility to withdraw > > > the resource, the system administrator does not want to do it by hand. > > Libvirt is also not a required component for VM lifecycles, it's an > optional management interface, but there are also VM lifecycles exactly > as you describe. A VM may want a given type of vGPU, there might be > multiple sources of that type and any instance is fungible to any > other. Such an mdev can be dynamically created, assigned to the VM, > and destroyed later. Why do we need to support "empty" mdevs that do > not reserve reserve resources until opened? The concept of available > instances is entirely lost with that approach and it creates an > environment that's difficult to support, resources may not be available > at the time the user attempts to access them. > > > I don't think that you should distinguish the cases by the presence of > > a management application. How can the mdev driver know what the > > intention behind using the device is? > > Absolutely, vfio is a userspace driver interface, it's not tailored to > VM usage and we cannot know the intentions of the user. > > > Would it make more sense to use a different mechanism to enforce that > > applications only use those handles they are supposed to use? Maybe > > cgroups? I don't think it's a good idea to push usage policy into the > > kernel. > > I agree, this sounds like a userspace problem, mdev supports dynamic > creation and removal of mdev devices, if there's an issue with > maintaining a set of standby devices that a user has access to, this > sounds like a userspace broker problem. It makes more sense to me to > have a model where a userspace application can make a request to a > broker and the broker can reply with "none available" rather than > having a set of devices on standby that may or may not work depending > on the system load and other users. Thanks, > > Alex I am sorry, I used a wrong mutt command when reply to Cornelia's last mail. The last reply dose not stay within this thread. So please let me repeat my point here. I should not have use libvirt as the example. But WarpDrive works in such scenario: 1. It supports thousands of processes. Take zip accelerator as an example, any application need data compression/decompression will need to interact with the accelerator. To support that, you have to create tens of thousands of mdev for their usage. I don't think it is a good idea to have so many devices in the system. 2. The application does not want to own the mdev for long. It just need an access point for the hardware service. If it has to interact with an management agent for allocation and release, this makes the problem complex. 3. The service is bound with the process. When the process exit, the resource should be released automatically. Kernel is the best place to monitor the state of the process. I agree this extending the concept of mdev. But again, it is cleaner than creating another facility for user land DMA. We just need to take mdev as an access point of the device: when it is open, the resource is given. It is not a device for a particular entity or instance. But it is still a device which can provide service of the hardware. Cornelia is worrying about resource starving. I think that can be solved by set restriction on the mdev itself. Mdev management agent dose not help much here. Management on the mdev itself can still lead to the status of running out of resource. Thanks -- -Kenneth(Hisilicon) ================================================================================ 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!