From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Philippe Brucker Subject: Re: [PATCH 03/37] iommu/sva: Manage process address spaces Date: Fri, 2 Mar 2018 16:19:31 +0000 Message-ID: <087d3daa-5b63-038b-a81e-92ab752fdd26@arm.com> References: <20180212183352.22730-1-jean-philippe.brucker@arm.com> <20180212183352.22730-4-jean-philippe.brucker@arm.com> <5A97A324.9050605@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <5A97A324.9050605-VuQAYsv1563Yd54FQh9/CA@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 To: Lu Baolu , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" Cc: Mark Rutland , "bharatku-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org" , "ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org" , Catalin Marinas , "xuzaibo-hv44wF8Li93QT0dZR+AlfA@public.gmane.org" , "ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , Will Deacon , "okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org" , "bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org" , "robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , Sudeep Holla , "rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org" , "dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org" , "christian.koenig-5C7GfCeVMHo@public.gmane.org" , "lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" List-Id: linux-acpi@vger.kernel.org On 01/03/18 06:52, Lu Baolu wrote: > Can the pasid management code be moved into a common library? > PASID is not stick to SVA. An IOMMU model device could be designed > to use PASID for second level translation (classical DMA translation) > as well. What do you mean by second level translation? Do you see a use-case with nesting translation within the host? I agree that PASID + classical DMA is desirable. A device driver would allocate PASIDs and perform iommu_sva_map(domain, pasid, iova, pa, size, prot) and iommu_sva_unmap(domain, pasid, iova, size). I'm hoping that we can also augment the DMA API with PASIDs, and that a driver can use both shared and private contexts simultaneously. So that it can use a few PASIDs for management purpose, and assign the rest to userspace. The intent is for iommu-sva.c to be this common library. Work for "private" PASID allocation is underway, see Jordan Crouse's series posted last week https://www.spinics.net/lists/arm-kernel/msg635857.html Thanks, Jean From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Return-Path: Date: Fri, 2 Mar 2018 16:19:31 +0000 From: Jean-Philippe Brucker To: Lu Baolu , "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" Subject: Re: [PATCH 03/37] iommu/sva: Manage process address spaces Message-ID: <087d3daa-5b63-038b-a81e-92ab752fdd26@arm.com> References: <20180212183352.22730-1-jean-philippe.brucker@arm.com> <20180212183352.22730-4-jean-philippe.brucker@arm.com> <5A97A324.9050605@linux.intel.com> MIME-Version: 1.0 In-Reply-To: <5A97A324.9050605@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , "bharatku@xilinx.com" , "ashok.raj@intel.com" , "shunyong.yang@hxt-semitech.com" , "rjw@rjwysocki.net" , Catalin Marinas , "xuzaibo@huawei.com" , "ilias.apalodimas@linaro.org" , Will Deacon , "okaya@codeaurora.org" , "bhelgaas@google.com" , "robh+dt@kernel.org" , Sudeep Holla , "rfranz@cavium.com" , "dwmw2@infradead.org" , "christian.koenig@amd.com" , "lenb@kernel.org" Content-Type: text/plain; charset="us-ascii" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+bjorn=helgaas.com@lists.infradead.org List-ID: On 01/03/18 06:52, Lu Baolu wrote: > Can the pasid management code be moved into a common library? > PASID is not stick to SVA. An IOMMU model device could be designed > to use PASID for second level translation (classical DMA translation) > as well. What do you mean by second level translation? Do you see a use-case with nesting translation within the host? I agree that PASID + classical DMA is desirable. A device driver would allocate PASIDs and perform iommu_sva_map(domain, pasid, iova, pa, size, prot) and iommu_sva_unmap(domain, pasid, iova, size). I'm hoping that we can also augment the DMA API with PASIDs, and that a driver can use both shared and private contexts simultaneously. So that it can use a few PASIDs for management purpose, and assign the rest to userspace. The intent is for iommu-sva.c to be this common library. Work for "private" PASID allocation is underway, see Jordan Crouse's series posted last week https://www.spinics.net/lists/arm-kernel/msg635857.html Thanks, Jean _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: jean-philippe.brucker@arm.com (Jean-Philippe Brucker) Date: Fri, 2 Mar 2018 16:19:31 +0000 Subject: [PATCH 03/37] iommu/sva: Manage process address spaces In-Reply-To: <5A97A324.9050605@linux.intel.com> References: <20180212183352.22730-1-jean-philippe.brucker@arm.com> <20180212183352.22730-4-jean-philippe.brucker@arm.com> <5A97A324.9050605@linux.intel.com> Message-ID: <087d3daa-5b63-038b-a81e-92ab752fdd26@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 01/03/18 06:52, Lu Baolu wrote: > Can the pasid management code be moved into a common library? > PASID is not stick to SVA. An IOMMU model device could be designed > to use PASID for second level translation (classical DMA translation) > as well. What do you mean by second level translation? Do you see a use-case with nesting translation within the host? I agree that PASID + classical DMA is desirable. A device driver would allocate PASIDs and perform iommu_sva_map(domain, pasid, iova, pa, size, prot) and iommu_sva_unmap(domain, pasid, iova, size). I'm hoping that we can also augment the DMA API with PASIDs, and that a driver can use both shared and private contexts simultaneously. So that it can use a few PASIDs for management purpose, and assign the rest to userspace. The intent is for iommu-sva.c to be this common library. Work for "private" PASID allocation is underway, see Jordan Crouse's series posted last week https://www.spinics.net/lists/arm-kernel/msg635857.html Thanks, Jean