From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Lee Subject: Re: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive Date: Sat, 11 Aug 2018 23:26:48 +0800 Message-ID: <6ea4dcfd-d539-93e4-acf1-d09ea35f0ddc@gmail.com> References: <20180802040557.GL160746@Turing-Arch-b> <20180802142243.GA3481@redhat.com> <20180803034721.GC91035@Turing-Arch-b> <20180803143944.GA4079@redhat.com> <20180806031252.GG91035@Turing-Arch-b> <20180806153257.GB6002@redhat.com> <11bace0e-dc14-5d2c-f65c-25b852f4e9ca@gmail.com> <20180808151835.GA3429@redhat.com> <20180809080352.GI91035@Turing-Arch-b> <20180809144613.GB3386@redhat.com> <20180810033913.GK91035@Turing-Arch-b> <0f6bac9b-8381-1874-9367-46b5f4cef56e@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Cc: "Tian, Kevin" , Alex Williamson , Herbert Xu , "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Greg Kroah-Hartman , Zaibo Xu , Jonathan Corbet , "Kumar, Sanjay K" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Philippe Ombredanne , Thomas Gleixner , Hao Fang , "David S . Miller" , "linux-accelerators-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" To: Jean-Philippe Brucker , Kenneth Lee , Jerome Glisse Return-path: In-Reply-To: <0f6bac9b-8381-1874-9367-46b5f4cef56e-5wv7dgnIgG8@public.gmane.org> Content-Language: en-US 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 CgrlnKggMjAxOOW5tDA45pyIMTDml6Ug5pif5pyf5LqUIDA5OjEyIOS4i+WNiCwgSmVhbi1QaGls aXBwZSBCcnVja2VyIOWGmemBkzoKPiBIaSBLZW5uZXRoLAo+Cj4gT24gMTAvMDgvMTggMDQ6Mzks IEtlbm5ldGggTGVlIHdyb3RlOgo+Pj4gWW91IGNhbiBhY2hpZXZlIGV2ZXJ5dGhpbmcgeW91IHdh bnQgdG8gYWNoaWV2ZSB3aXRoIGV4aXN0aW5nIHVwc3RyZWFtCj4+PiBzb2x1dGlvbi4gUmUtaW52 ZW50aW5nIGEgd2hvbGUgbmV3IGRyaXZlciBpbmZyYXN0cnVjdHVyZSBzaG91bGQgcmVhbGx5Cj4+ PiBiZSBtb3RpdmF0ZWQgd2l0aCBzdHJvbmcgYW5kIG9idmlvdXMgcmVhc29ucy4KPj4gSSB3YW50 IHRvIHVuZGVyc3RhbmQgYmV0dGVyIG9mIHlvdXIgaWRlYS4gSWYgSSBjcmVhdGUgc29tZSB1bmlm aWVkIGhlbHBlcgo+PiBBUElzIGluIGRyaXZlcnMvaW9tbXUvLCBzYXk6Cj4+Cj4+IAl3ZF9jcmVh dGVfZGV2KHBhcmVudF9kZXYsIHdkX2RldikKPj4gCXdkX3JlbGVhc2VfZGV2KHdkX2RldikKPj4K Pj4gVGhlIEFQSSBjcmVhdGUgY2hyZGV2IHRvIHRha2UgcmVxdWVzdCBmcm9tIHVzZXIgc3BhY2Ug Zm9yIG9wZW4ocmVzb3VyY2UKPj4gYWxsb2NhdGlvbiksIGlvbWFwLCBlcG9sbCAoaXJxKSwgYW5k IGRtYV9tYXAod2l0aCBwYXNpZCBhdXRvbWF0aWNhbGx5KS4KPj4KPj4gRG8geW91IHRoaW5rIGl0 IGlzIGFjY2VwdGFibGU/Cj4gTWF5YmUgbm90IGRyaXZlcnMvaW9tbXUvIDopIFRoYXQgc3Vic3lz dGVtIG9ubHkgY29udGFpbnMgdG9vbHMgZm9yCj4gZGVhbGluZyB3aXRoIERNQSwgSSBkb24ndCB0 aGluayBlcG9sbCwgcmVzb3VyY2UgZW51bWVyYXRpb24gb3IgaW9tYXAgZml0Cj4gaW4gdGhlcmUu Clllcy4gSSBzaG91bGQgY29uc2lkZXIgd2hlcmUgdG8gcHV0IGl0IGNhcmVmdWxseS4KPgo+IENy ZWF0aW5nIG5ldyBoZWxwZXJzIHNlZW1zIHRvIGJlIHByZWNpc2VseSB3aGF0IHdlJ3JlIHRyeWlu ZyB0byBhdm9pZCBpbgo+IHRoaXMgdGhyZWFkLCBhbmQgdmZpby1tZGV2IGRvZXMgcHJvdmlkZSB0 aGUgY29tcG9uZW50cyB0aGF0IHlvdQo+IGRlc2NyaWJlLCBzbyBJIHdvdWxkbid0IGRpc2NhcmQg aXQgcmlnaHQgYXdheS4gV2hlbiB0aGUgR1BVLCBuZXQsIGJsb2NrCj4gb3IgYW5vdGhlciBzdWJz eXN0ZW0gZG9lc24ndCBmaXQgeW91ciBuZWVkcywgZWl0aGVyIGJlY2F1c2UgeW91cgo+IGFjY2Vs ZXJhdG9yIHByb3ZpZGVzIHNvbWUgc3BlY2lhbGl6ZWQgZnVuY3Rpb24sIG9yIGJlY2F1c2UgZm9y Cj4gcGVyZm9ybWFuY2UgcmVhc29ucyB5b3VyIGNsaWVudCB3YW50cyBkaXJlY3QgTU1JTyBhY2Nl c3MsIHlvdSBjYW4gYXQKPiBsZWFzdCBidWlsZCB5b3VyIGRyaXZlciBhbmQgbGlicmFyeSBvbiB0 b3Agb2YgdGhvc2UgZXhpc3RpbmcgVkZJTwo+IGNvbXBvbmVudHM6Cj4KPiAqIG9wZW4gYWxsb2Nh dGVzIGEgcGFydGl0aW9uIG9mIGFuIGFjY2VsZXJhdG9yLgo+ICogdmZpb19kZXZpY2VfaW5mbywg dmZpb19yZWdpb25faW5mbyBhbmQgdmZpb19pcnFfaW5mbyBlbnVtZXJhdGVzCj4gYXZhaWxhYmxl IHJlc291cmNlcy4KPiAqIHZmaW9faXJxX3NldCBkZWFscyB3aXRoIGVwb2xsLgo+ICogbW1hcCBn aXZlcyB5b3UgYSBwcml2YXRlIE1NSU8gZG9vcmJlbGwuCj4gKiB2ZmlvX2lvbW11X3R5cGUxIHBy b3ZpZGVzIHRoZSBETUEgb3BlcmF0aW9ucy4KPgo+IEN1cnJlbnRseSBtaXNzaW5nOgo+Cj4gKiBT aGFyaW5nIHRoZSBwYXJlbnQgSU9NTVUgYmV0d2VlbiBtZGV2LCB3aGljaCBpcyBhbHNvIHdoYXQg dGhlICJJT01NVQo+IGF3YXJlIG1lZGlhdGVkIGRldmljZSIgc2VyaWVzIHRhY2tsZXMsIGFuZCBz ZWVtcyBsaWtlIGEgbG9naWNhbCBhZGRpdGlvbgo+IHRvIFZGSU8uIEknZCBhcmd1ZSB0aGF0IHRo ZSBleGlzdGluZyBJT01NVSBvcHMgKG9yIG9uZXMgaW1wbGVtZW50ZWQgYnkKPiB0aGUgU1ZBIHNl cmllcykgY2FuIGJlIHVzZWQgdG8gZGVhbCB3aXRoIHRoaXMKPgo+ICogVGhlIGludGVyZmFjZSB0 byBkaXNjb3ZlciBhbiBhY2NlbGVyYXRvciBuZWFyIHlvdXIgbWVtb3J5IG5vZGUsIG9yIG9uZQo+ IHRoYXQgeW91IGNhbiBjaGFpbiB3aXRoIG90aGVyIGRldmljZXMuIElmIEkgdW5kZXJzdG9vZCBj b3JyZWN0bHkgdGhlCj4gY29uY2x1c2lvbiB3YXMgdGhhdCB0aGUgQVBJIChhIHRvcG9sb2d5IGRl c2NyaXB0aW9uIGluIHN5c2ZzPykgc2hvdWxkIGJlCj4gY29tbW9uIHRvIHZhcmlvdXMgc3Vic3lz dGVtcywgaW4gd2hpY2ggY2FzZSB2ZmlvLW1kZXYgKG9yIHRoZSBtZWRpYXRpbmcKPiBkcml2ZXIp IGNvdWxkIGFsc28gdXNlIGl0Lgo+Cj4gKiBUaGUgcXVldWUgYWJzdHJhY3Rpb24gZGlzY3Vzc2Vk IG9uIHBhdGNoIDMvNy4gUGVyaGFwcyB0aGUgY3VycmVudCB2ZmlvCj4gcmVzb3VyY2UgZGVzY3Jp cHRpb24gb2YgTU1JTyBhbmQgSVJRIGlzIHN1ZmZpY2llbnQgaGVyZSBhcyB3ZWxsLCBzaW5jZQo+ IHZlbmRvcnMgdGVuZCB0byBlYWNoIGltcGxlbWVudCB0aGVpciBvd24gcXVldWUgc2NoZW1lcy4g SWYgeW91IG5lZWQKPiBhZGRpdGlvbmFsIGZlYXR1cmVzLCByZWFkL3dyaXRlIGZvcHMgZ2l2ZSB0 aGUgbWVkaWF0aW5nIGRyaXZlciBhIGxvdCBvZgo+IGZyZWVkb20uIFRvIHN1cHBvcnQgZmVhdHVy ZXMgdGhhdCBhcmUgdG9vIHNwZWNpZmljIGZvciBkcml2ZXJzL3ZmaW8vIHlvdQo+IGNhbiBpbXBs ZW1lbnQgYSBjb25maWcgc3BhY2Ugd2l0aCBjYXBhYmlsaXRpZXMgYW5kIHJlZ2lzdGVycyBvZiB5 b3VyCj4gY2hvaWNlLiBJZiB5b3UncmUgdmVyc2lvbmluZyB0aGUgY2FwYWJpbGl0aWVzLCB0aGUg Y29kZSB0byBoYW5kbGUgdGhlbQo+IGNvdWxkIGV2ZW4gYmUgc2hhcmVkIGJldHdlZW4gZGlmZmVy ZW50IGFjY2VsZXJhdG9yIGRyaXZlcnMgYW5kIGxpYnJhcmllcy4KVGhhbmsgeW91LCBKZWFuLAoK VGhlIG1ham9yIHJlYXNvbiB0aGF0IEkgd2FudCB0byByZW1vdmUgZGVwZW5kZW5jeSB0byBWRklP IGlzOiBJIGFjY2VwdGVkIAp0aGF0IHRoZSB3aG9sZSBsb2dpYyBvZiBWRklPIHdhcyBidWlsdCBv biB0aGUgaWRlYSBvZiBjcmVhdGluZyB2aXJ0dWFsIApkZXZpY2UuCgpMZXQncyBjb25zaWRlciBp dCBpbiB0aGlzIHdheTogV2UgaGF2ZSBoYXJkd2FyZSB3aXRoIElPTU1VIHN1cHBvcnQuIFNvIAp3 ZSBjcmVhdGUgYSBkZWZhdWx0X2RvbWFpbiB0byB0aGUgcGFydGljdWxhciBJT01NVSAodW5pdCkg aW4gdGhlIGdyb3VwIApmb3IgdGhlIGtlcm5lbCBkcml2ZXIgdG8gdXNlIGl0LiBOb3cgdGhlIGRl dmljZSBpcyBnb2luZyB0byBiZSB1c2VkIGJ5IGEgClZNIG9yIGEgQ29udGFpbmVyLiBTbyB3ZSB1 bmJpbmQgaXQgZnJvbSB0aGUgb3JpZ2luYWwgZHJpdmVyLCBhbmQgcHV0IHRoZSAKZGVmYXVsdF9k b21haW4gYXdheSzCoCBjcmVhdGUgYSBuZXcgZG9tYWluIGZvciB0aGlzIHBhcnRpY3VsYXIgdXNl IGNhc2UuwqAgClNvIG5vdyB0aGUgZGV2aWNlIHNob3dzIHVwIGFzIGEgcGxhdGZvcm0gb3IgcGNp IGRldmljZSB0byB0aGUgdXNlciAKc3BhY2UuIFRoaXMgaXMgd2hhdCBWRklPIHRyeSB0byBwcm92 aWRlLiBNZGV2IGV4dGVuZHMgdGhlIHNjZW5hcmlvIGJ1dCAKZG9zZSBub3QgY2hhbmdlIHRoZSBp bnRlbnRpb24uIEFuZCBJIHRoaW5rIHRoYXQgaXMgd2h5IEFsZXggZW1waGFzaXMgCnByZS1hbGxv Y2F0aW5nIHJlc291cmNlIHRvIHRoZSBtZGV2LgoKQnV0IHdoYXQgV2FycERyaXZlIG5lZWQgaXMg dG8gZ2V0IHNlcnZpY2UgZnJvbSB0aGUgaGFyZHdhcmUgaXRzZWxmIGFuZCAKc2V0IG1hcHBpbmcg dG8gaXRzIGN1cnJlbnQgZG9tYWluLCBha2EgZGVmYXV0X2RvbWFpbi4gSWYgd2UgZG8gaXQgaW4g ClZGSU8tbWRldiwgaXQgbG9va3MgbGlrZSB0aGUgVkZJTyBmcmFtZXdvcmsgdGFrZXMgYWxsIHRo ZSBlZmZvcnQgdG8gcHV0IAp0aGUgZGVmYXVsdF9kb21haW4gYXdheSBhbmQgY3JlYXRlIGEgbmV3 IG9uZSBhbmQgYmUgcmVhZHkgZm9yIHVzZXIgc3BhY2UgCnRvIHVzZS4gQnV0IEkgdGVsbCBoaW0g c3RvcCB1c2luZyB0aGUgbmV3IGRvbWFpbiBhbmQgdHJ5IHRoZSBvcmlnaW5hbCBvbmUuLi4KCkl0 IGlzIG5vdCByZWFzb25hYmxlLCBpc24ndCBpdDopCgpTbyB3aHkgZG9uJ3QgSSBqdXN0IHRha2Ug dGhlIHJlcXVlc3QgYW5kIHNldCBpdCBpbnRvIHRoZSBkZWZhdWx0X2RvbWFpbiAKZGlyZWN0bHk/ IFRoZSB0cnVlIHJlcXVpcmVtZW50IG9mIFdhcnBEcml2ZSBpcyB0byBsZXQgcHJvY2VzcyBzZXQg dGhlIApwYWdlIHRhYmxlIGZvciBwYXJ0aWN1bGFyIHBhc2lkIG9yIHN1YnN0cmVhbSBpZCwgc28g aXQgY2FuIGFjY2VwdCAKY29tbWFuZCB3aXRoIGFkZHJlc3MgaW4gdGhlIHByb2Nlc3Mgc3BhY2Uu IEl0IG5lZWRzIG5vIGRldmljZS4KCiBGcm9tIHRoaXMgcGVyc3BlY3RpdmUsIGl0IHNlZW1zIHRo ZXJlIGlzIG5vIHJlYXNvbiB0byBrZWVwIGl0IGluIFZGSU8uCgpUaGFua3MKS2VubmV0aAo+Cj4g VGhhbmtzLAo+IEplYW4KPgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KaW9tbXUgbWFpbGluZyBsaXN0CmlvbW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24u b3JnCmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9uLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lv bW11 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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham 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 A57E37D00A for ; Sat, 11 Aug 2018 15:27:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727396AbeHKSBp (ORCPT ); Sat, 11 Aug 2018 14:01:45 -0400 Received: from mail-qt0-f193.google.com ([209.85.216.193]:44805 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727386AbeHKSBp (ORCPT ); Sat, 11 Aug 2018 14:01:45 -0400 Received: by mail-qt0-f193.google.com with SMTP id b15-v6so13299793qtp.11; Sat, 11 Aug 2018 08:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=NjiOtMwrkE7eCLR5P4cIM8UwS1FO/jhA5jzal0l5upU=; b=drAo4IM+qziWZucV/j3zNicqfcRYRG/9CA80UlUdmQ6n8JE6JoeVjPhT8LDPlrgWWn Z/RtzYqT4mH96pbwXLS2XrmWM5Bdts4mNNW+bGztX2Bv4UERz+9WvjN1eb/zZAjCuxQx DkI37piHbZJTL1SpOGXUwnRc/0m9krt4cxm/8TER5M8LbkTtGghE3cSae91sN0u1VNx8 Ya2iTfpW9C/IigwQolhLF9A2zL4NTIw4g/cVnAG7OaZWmtsIWFnl/VoxsAlNGJ232367 N6GIVbnh4UaJI6K9cm0Qi4GuSb2D5dVdGV2UB/wYN7lQkXln2Md2QhQAsG6a7mBvOjr/ 4qLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=NjiOtMwrkE7eCLR5P4cIM8UwS1FO/jhA5jzal0l5upU=; b=POD3Dyk/BidhavESAhF+ZTPNGDkkowuL+Sg4YEYX0FDU30Uj9PUcV5kJK0J6HWRTEB 4b2qrAB+iWSWuSWWYTY/psZGjjQ+ch2SnlBPW6FlRiWH/MGnclm23JhVQ1t/OohmI4pb /hYhoLt6NkflnZex2saGC3FfGEDBVeqO+IMu/RNqTSgogvAzI1kyc6idGIhHyZGPY0uL gW4UfQQ1OwjzT8Uhsw/Jit3OUoE2kapMKNzjUKv2bVS2Hh2pei9uh5eEH9KE0bGphHdi sT1BVc4FX8HX3LC1dJWuCWl3RxAgUZDMRR+eCRNQIbxTSKWg2wW4Mg94/ngSOsqO3ZpW ueFw== X-Gm-Message-State: AOUpUlED8XsqhNDNIdhmfOFg9/LwkhyaZZTsX8neKnEw0V22w9VjTMeN cYR64Qek3LxLrqbFtAj1qG4= X-Google-Smtp-Source: AA+uWPzauWeIyWrUJvXzOZWQHuaikxUaQtJEdzgcRGTT4khWHnPHX6ZHUzJDagMVhrWVjnuskXZgqg== X-Received: by 2002:ac8:70c5:: with SMTP id g5-v6mr10509230qtp.376.1534001232266; Sat, 11 Aug 2018 08:27:12 -0700 (PDT) Received: from [10.151.0.126] ([104.237.86.7]) by smtp.gmail.com with ESMTPSA id d202-v6sm7238291qkb.38.2018.08.11.08.26.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Aug 2018 08:27:11 -0700 (PDT) Subject: Re: [RFC PATCH 0/7] A General Accelerator Framework, WarpDrive To: Jean-Philippe Brucker , Kenneth Lee , Jerome Glisse Cc: Herbert Xu , "kvm@vger.kernel.org" , Jonathan Corbet , Greg Kroah-Hartman , Zaibo Xu , "linux-doc@vger.kernel.org" , "Kumar, Sanjay K" , "Tian, Kevin" , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linuxarm@huawei.com" , Alex Williamson , "linux-crypto@vger.kernel.org" , Philippe Ombredanne , Thomas Gleixner , Hao Fang , "David S . Miller" , "linux-accelerators@lists.ozlabs.org" References: <20180802040557.GL160746@Turing-Arch-b> <20180802142243.GA3481@redhat.com> <20180803034721.GC91035@Turing-Arch-b> <20180803143944.GA4079@redhat.com> <20180806031252.GG91035@Turing-Arch-b> <20180806153257.GB6002@redhat.com> <11bace0e-dc14-5d2c-f65c-25b852f4e9ca@gmail.com> <20180808151835.GA3429@redhat.com> <20180809080352.GI91035@Turing-Arch-b> <20180809144613.GB3386@redhat.com> <20180810033913.GK91035@Turing-Arch-b> <0f6bac9b-8381-1874-9367-46b5f4cef56e@arm.com> From: Kenneth Lee Message-ID: <6ea4dcfd-d539-93e4-acf1-d09ea35f0ddc@gmail.com> Date: Sat, 11 Aug 2018 23:26:48 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0f6bac9b-8381-1874-9367-46b5f4cef56e@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 在 2018年08月10日 星期五 09:12 下午, Jean-Philippe Brucker 写道: > Hi Kenneth, > > On 10/08/18 04:39, Kenneth Lee wrote: >>> You can achieve everything you want to achieve with existing upstream >>> solution. Re-inventing a whole new driver infrastructure should really >>> be motivated with strong and obvious reasons. >> I want to understand better of your idea. If I create some unified helper >> APIs in drivers/iommu/, say: >> >> wd_create_dev(parent_dev, wd_dev) >> wd_release_dev(wd_dev) >> >> The API create chrdev to take request from user space for open(resource >> allocation), iomap, epoll (irq), and dma_map(with pasid automatically). >> >> Do you think it is acceptable? > Maybe not drivers/iommu/ :) That subsystem only contains tools for > dealing with DMA, I don't think epoll, resource enumeration or iomap fit > in there. Yes. I should consider where to put it carefully. > > Creating new helpers seems to be precisely what we're trying to avoid in > this thread, and vfio-mdev does provide the components that you > describe, so I wouldn't discard it right away. When the GPU, net, block > or another subsystem doesn't fit your needs, either because your > accelerator provides some specialized function, or because for > performance reasons your client wants direct MMIO access, you can at > least build your driver and library on top of those existing VFIO > components: > > * open allocates a partition of an accelerator. > * vfio_device_info, vfio_region_info and vfio_irq_info enumerates > available resources. > * vfio_irq_set deals with epoll. > * mmap gives you a private MMIO doorbell. > * vfio_iommu_type1 provides the DMA operations. > > Currently missing: > > * Sharing the parent IOMMU between mdev, which is also what the "IOMMU > aware mediated device" series tackles, and seems like a logical addition > to VFIO. I'd argue that the existing IOMMU ops (or ones implemented by > the SVA series) can be used to deal with this > > * The interface to discover an accelerator near your memory node, or one > that you can chain with other devices. If I understood correctly the > conclusion was that the API (a topology description in sysfs?) should be > common to various subsystems, in which case vfio-mdev (or the mediating > driver) could also use it. > > * The queue abstraction discussed on patch 3/7. Perhaps the current vfio > resource description of MMIO and IRQ is sufficient here as well, since > vendors tend to each implement their own queue schemes. If you need > additional features, read/write fops give the mediating driver a lot of > freedom. To support features that are too specific for drivers/vfio/ you > can implement a config space with capabilities and registers of your > choice. If you're versioning the capabilities, the code to handle them > could even be shared between different accelerator drivers and libraries. Thank you, Jean, The major reason that I want to remove dependency to VFIO is: I accepted that the whole logic of VFIO was built on the idea of creating virtual device. Let's consider it in this way: We have hardware with IOMMU support. So we create a default_domain to the particular IOMMU (unit) in the group for the kernel driver to use it. Now the device is going to be used by a VM or a Container. So we unbind it from the original driver, and put the default_domain away,  create a new domain for this particular use case.  So now the device shows up as a platform or pci device to the user space. This is what VFIO try to provide. Mdev extends the scenario but dose not change the intention. And I think that is why Alex emphasis pre-allocating resource to the mdev. But what WarpDrive need is to get service from the hardware itself and set mapping to its current domain, aka defaut_domain. If we do it in VFIO-mdev, it looks like the VFIO framework takes all the effort to put the default_domain away and create a new one and be ready for user space to use. But I tell him stop using the new domain and try the original one... It is not reasonable, isn't it:) So why don't I just take the request and set it into the default_domain directly? The true requirement of WarpDrive is to let process set the page table for particular pasid or substream id, so it can accept command with address in the process space. It needs no device. From this perspective, it seems there is no reason to keep it in VFIO. Thanks Kenneth > > Thanks, > Jean >