From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id CF3C16B026A for ; Thu, 24 May 2018 07:50:47 -0400 (EDT) Received: by mail-wm0-f70.google.com with SMTP id e1-v6so1006444wma.3 for ; Thu, 24 May 2018 04:50:47 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id d7-v6sor3200729wrq.34.2018.05.24.04.50.46 for (Google Transport Security); Thu, 24 May 2018 04:50:46 -0700 (PDT) Date: Thu, 24 May 2018 14:50:39 +0300 From: Ilias Apalodimas Subject: Re: [PATCH v2 03/40] iommu/sva: Manage process address spaces Message-ID: <20180524115039.GA10260@apalos> References: <20180511190641.23008-1-jean-philippe.brucker@arm.com> <20180511190641.23008-4-jean-philippe.brucker@arm.com> <20180516163117.622693ea@jacob-builder> <20180522094334.71f0e36b@jacob-builder> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Jean-Philippe Brucker Cc: Jacob Pan , "linux-arm-kernel@lists.infradead.org" , "linux-pci@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "devicetree@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "kvm@vger.kernel.org" , "linux-mm@kvack.org" , "joro@8bytes.org" , Will Deacon , Robin Murphy , "alex.williamson@redhat.com" , "tn@semihalf.com" , "liubo95@huawei.com" , "thunder.leizhen@huawei.com" , "xieyisheng1@huawei.com" , "xuzaibo@huawei.com" , "jonathan.cameron@huawei.com" , "liudongdong3@huawei.com" , "shunyong.yang@hxt-semitech.com" , "nwatters@codeaurora.org" , "okaya@codeaurora.org" , "jcrouse@codeaurora.org" , "rfranz@cavium.com" , "dwmw2@infradead.org" , "yi.l.liu@intel.com" , "ashok.raj@intel.com" , "kevin.tian@intel.com" , "baolu.lu@linux.intel.com" , "robdclark@gmail.com" , "christian.koenig@amd.com" , "bharatku@xilinx.com" , "rgummal@xilinx.com" > Interesting, I hadn't thought about this use-case before. At first I > thought you were talking about mdev devices assigned to VMs, but I think > you're referring to mdevs assigned to userspace drivers instead? Out of > curiosity, is it only theoretical or does someone actually need this? There has been some non upstreamed efforts to have mdev and produce userspace drivers. Huawei is using it on what they call "wrapdrive" for crypto devices and we did a proof of concept for ethernet interfaces. At the time we choose not to involve the IOMMU for the reason you mentioned, but having it there would be good. Thanks Ilias