From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christian_K=c3=b6nig?= Subject: Re: [PATCH 03/37] iommu/sva: Manage process address spaces Date: Thu, 1 Mar 2018 09:04:58 +0100 Message-ID: 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"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: 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 , Jean-Philippe Brucker , 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-5wv7dgnIgG8@public.gmane.org, bharatku-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org, ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org, catalin.marinas-5wv7dgnIgG8@public.gmane.org, xuzaibo-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, will.deacon-5wv7dgnIgG8@public.gmane.org, okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, sudeep.holla-5wv7dgnIgG8@public.gmane.org, rfranz-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org List-Id: linux-acpi@vger.kernel.org Am 01.03.2018 um 07:52 schrieb Lu Baolu: > Hi Jean, > > On 02/13/2018 02:33 AM, Jean-Philippe Brucker wrote: >> [SNIP] >> + pasid = idr_alloc_cyclic(&iommu_pasid_idr, io_mm, dev_param->min_pasid, >> + dev_param->max_pasid + 1, GFP_ATOMIC); > 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. Yeah, we have the same problem on amdgpu. We assign PASIDs to clients even when IOMMU isn't present in the system just because we need it for debugging. E.g. when the hardware detects that some shader program is doing something nasty we get the PASID in the interrupt and could for example use it to inform the client about the fault. Regards, Christian. > > Best regards, > Lu Baolu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [PATCH 03/37] iommu/sva: Manage process address spaces To: Lu Baolu , Jean-Philippe Brucker , 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 Cc: mark.rutland@arm.com, ilias.apalodimas@linaro.org, catalin.marinas@arm.com, xuzaibo@huawei.com, will.deacon@arm.com, okaya@codeaurora.org, ashok.raj@intel.com, bharatku@xilinx.com, rfranz@cavium.com, lenb@kernel.org, robh+dt@kernel.org, bhelgaas@google.com, shunyong.yang@hxt-semitech.com, dwmw2@infradead.org, rjw@rjwysocki.net, sudeep.holla@arm.com References: <20180212183352.22730-1-jean-philippe.brucker@arm.com> <20180212183352.22730-4-jean-philippe.brucker@arm.com> <5A97A324.9050605@linux.intel.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Thu, 1 Mar 2018 09:04:58 +0100 MIME-Version: 1.0 In-Reply-To: <5A97A324.9050605@linux.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Sender: linux-acpi-owner@vger.kernel.org List-ID: Am 01.03.2018 um 07:52 schrieb Lu Baolu: > Hi Jean, > > On 02/13/2018 02:33 AM, Jean-Philippe Brucker wrote: >> [SNIP] >> + pasid = idr_alloc_cyclic(&iommu_pasid_idr, io_mm, dev_param->min_pasid, >> + dev_param->max_pasid + 1, GFP_ATOMIC); > 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. Yeah, we have the same problem on amdgpu. We assign PASIDs to clients even when IOMMU isn't present in the system just because we need it for debugging. E.g. when the hardware detects that some shader program is doing something nasty we get the PASID in the interrupt and could for example use it to inform the client about the fault. Regards, Christian. > > Best regards, > Lu Baolu From mboxrd@z Thu Jan 1 00:00:00 1970 From: christian.koenig@amd.com (=?UTF-8?Q?Christian_K=c3=b6nig?=) Date: Thu, 1 Mar 2018 09:04:58 +0100 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: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Am 01.03.2018 um 07:52 schrieb Lu Baolu: > Hi Jean, > > On 02/13/2018 02:33 AM, Jean-Philippe Brucker wrote: >> [SNIP] >> + pasid = idr_alloc_cyclic(&iommu_pasid_idr, io_mm, dev_param->min_pasid, >> + dev_param->max_pasid + 1, GFP_ATOMIC); > 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. Yeah, we have the same problem on amdgpu. We assign PASIDs to clients even when IOMMU isn't present in the system just because we need it for debugging. E.g. when the hardware detects that some shader program is doing something nasty we get the PASID in the interrupt and could for example use it to inform the client about the fault. Regards, Christian. > > Best regards, > Lu Baolu