From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Auger Subject: Re: [RFC v3 07/15] iommu: iommu_get/put_single_reserved Date: Thu, 18 Feb 2016 18:18:44 +0100 Message-ID: <56C5FCF4.4010509@linaro.org> References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org> <1455264797-2334-8-git-send-email-eric.auger@linaro.org> <20160218110616.05108071@arm.com> <56C5F472.1020003@linaro.org> <56C5F679.8000002@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56C5F679.8000002-5wv7dgnIgG8@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 To: Marc Zyngier Cc: eric.auger-qxv4g6HH51o@public.gmane.org, kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, will.deacon-5wv7dgnIgG8@public.gmane.org, brijesh.singh-5C7GfCeVMHo@public.gmane.org, kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org, p.fedin-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, Thomas.Lendacky-5C7GfCeVMHo@public.gmane.org, jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org, patches-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Manish.Jaggi-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, sherry.hurwitz-5C7GfCeVMHo@public.gmane.org, christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org List-Id: kvmarm@lists.cs.columbia.edu Hi Marc, On 02/18/2016 05:51 PM, Marc Zyngier wrote: > On 18/02/16 16:42, Eric Auger wrote: >> Hello, >> On 02/18/2016 12:06 PM, Marc Zyngier wrote: >>> On Fri, 12 Feb 2016 08:13:09 +0000 >>> Eric Auger wrote: >>> >>>> This patch introduces iommu_get/put_single_reserved. >>>> >>>> iommu_get_single_reserved allows to allocate a new reserved iova page >>>> and map it onto the physical page that contains a given physical address. >>>> It returns the iova that is mapped onto the provided physical address. >>>> Hence the physical address passed in argument does not need to be aligned. >>>> >>>> In case a mapping already exists between both pages, the IOVA mapped >>>> to the PA is directly returned. >>>> >>>> Each time an iova is successfully returned a binding ref count is >>>> incremented. >>>> >>>> iommu_put_single_reserved decrements the ref count and when this latter >>>> is null, the mapping is destroyed and the iova is released. >>> >>> I wonder if there is a requirement for the caller to find out about the >>> size of the mapping, or to impose a given size... MSIs clearly do not >>> have that requirement (this is always a 32bit value), but since. >>> allocations usually pair address and size, I though I'd ask... >> Yes. Currently this only makes sure the host PA is mapped and returns >> the corresponding IOVA. It is part of the discussion we need to have on >> the API besides the problematic of which API it should belong to. > > One of the issues I have with the API at the moment is that there is no > control on the page size. Imagine you have allocated a 4kB IOVA window > for your MSI, but your IOMMU can only map 64kB (not unreasonable to > imagine on arm64). What happens then? The code checks the IOVA window size is aligned with the IOMMU page size so I think that case is handled at iova domain creation (arm_smmu_alloc_reserved_iova_domain). > > Somehow, userspace should be told about it, one way or another. I agree on that point. The user-space should be provided with the information about the requested iova pool size and alignments. This is missing in current rfc series. Best Regards Eric > > Thanks, > > M. > From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric.auger@linaro.org (Eric Auger) Date: Thu, 18 Feb 2016 18:18:44 +0100 Subject: [RFC v3 07/15] iommu: iommu_get/put_single_reserved In-Reply-To: <56C5F679.8000002@arm.com> References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org> <1455264797-2334-8-git-send-email-eric.auger@linaro.org> <20160218110616.05108071@arm.com> <56C5F472.1020003@linaro.org> <56C5F679.8000002@arm.com> Message-ID: <56C5FCF4.4010509@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Marc, On 02/18/2016 05:51 PM, Marc Zyngier wrote: > On 18/02/16 16:42, Eric Auger wrote: >> Hello, >> On 02/18/2016 12:06 PM, Marc Zyngier wrote: >>> On Fri, 12 Feb 2016 08:13:09 +0000 >>> Eric Auger wrote: >>> >>>> This patch introduces iommu_get/put_single_reserved. >>>> >>>> iommu_get_single_reserved allows to allocate a new reserved iova page >>>> and map it onto the physical page that contains a given physical address. >>>> It returns the iova that is mapped onto the provided physical address. >>>> Hence the physical address passed in argument does not need to be aligned. >>>> >>>> In case a mapping already exists between both pages, the IOVA mapped >>>> to the PA is directly returned. >>>> >>>> Each time an iova is successfully returned a binding ref count is >>>> incremented. >>>> >>>> iommu_put_single_reserved decrements the ref count and when this latter >>>> is null, the mapping is destroyed and the iova is released. >>> >>> I wonder if there is a requirement for the caller to find out about the >>> size of the mapping, or to impose a given size... MSIs clearly do not >>> have that requirement (this is always a 32bit value), but since. >>> allocations usually pair address and size, I though I'd ask... >> Yes. Currently this only makes sure the host PA is mapped and returns >> the corresponding IOVA. It is part of the discussion we need to have on >> the API besides the problematic of which API it should belong to. > > One of the issues I have with the API at the moment is that there is no > control on the page size. Imagine you have allocated a 4kB IOVA window > for your MSI, but your IOMMU can only map 64kB (not unreasonable to > imagine on arm64). What happens then? The code checks the IOVA window size is aligned with the IOMMU page size so I think that case is handled at iova domain creation (arm_smmu_alloc_reserved_iova_domain). > > Somehow, userspace should be told about it, one way or another. I agree on that point. The user-space should be provided with the information about the requested iova pool size and alignments. This is missing in current rfc series. Best Regards Eric > > Thanks, > > M. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1947197AbcBRRTS (ORCPT ); Thu, 18 Feb 2016 12:19:18 -0500 Received: from mail-wm0-f43.google.com ([74.125.82.43]:36467 "EHLO mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1947119AbcBRRTQ (ORCPT ); Thu, 18 Feb 2016 12:19:16 -0500 Subject: Re: [RFC v3 07/15] iommu: iommu_get/put_single_reserved To: Marc Zyngier References: <1455264797-2334-1-git-send-email-eric.auger@linaro.org> <1455264797-2334-8-git-send-email-eric.auger@linaro.org> <20160218110616.05108071@arm.com> <56C5F472.1020003@linaro.org> <56C5F679.8000002@arm.com> Cc: eric.auger@st.com, alex.williamson@redhat.com, will.deacon@arm.com, joro@8bytes.org, tglx@linutronix.de, jason@lakedaemon.net, christoffer.dall@linaro.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, suravee.suthikulpanit@amd.com, patches@linaro.org, linux-kernel@vger.kernel.org, Manish.Jaggi@caviumnetworks.com, Bharat.Bhushan@freescale.com, pranav.sawargaonkar@gmail.com, p.fedin@samsung.com, iommu@lists.linux-foundation.org, sherry.hurwitz@amd.com, brijesh.singh@amd.com, leo.duran@amd.com, Thomas.Lendacky@amd.com From: Eric Auger Message-ID: <56C5FCF4.4010509@linaro.org> Date: Thu, 18 Feb 2016 18:18:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C5F679.8000002@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc, On 02/18/2016 05:51 PM, Marc Zyngier wrote: > On 18/02/16 16:42, Eric Auger wrote: >> Hello, >> On 02/18/2016 12:06 PM, Marc Zyngier wrote: >>> On Fri, 12 Feb 2016 08:13:09 +0000 >>> Eric Auger wrote: >>> >>>> This patch introduces iommu_get/put_single_reserved. >>>> >>>> iommu_get_single_reserved allows to allocate a new reserved iova page >>>> and map it onto the physical page that contains a given physical address. >>>> It returns the iova that is mapped onto the provided physical address. >>>> Hence the physical address passed in argument does not need to be aligned. >>>> >>>> In case a mapping already exists between both pages, the IOVA mapped >>>> to the PA is directly returned. >>>> >>>> Each time an iova is successfully returned a binding ref count is >>>> incremented. >>>> >>>> iommu_put_single_reserved decrements the ref count and when this latter >>>> is null, the mapping is destroyed and the iova is released. >>> >>> I wonder if there is a requirement for the caller to find out about the >>> size of the mapping, or to impose a given size... MSIs clearly do not >>> have that requirement (this is always a 32bit value), but since. >>> allocations usually pair address and size, I though I'd ask... >> Yes. Currently this only makes sure the host PA is mapped and returns >> the corresponding IOVA. It is part of the discussion we need to have on >> the API besides the problematic of which API it should belong to. > > One of the issues I have with the API at the moment is that there is no > control on the page size. Imagine you have allocated a 4kB IOVA window > for your MSI, but your IOMMU can only map 64kB (not unreasonable to > imagine on arm64). What happens then? The code checks the IOVA window size is aligned with the IOMMU page size so I think that case is handled at iova domain creation (arm_smmu_alloc_reserved_iova_domain). > > Somehow, userspace should be told about it, one way or another. I agree on that point. The user-space should be provided with the information about the requested iova pool size and alignments. This is missing in current rfc series. Best Regards Eric > > Thanks, > > M. >