Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp963714ybm; Wed, 27 May 2020 12:18:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwSpPwtpMUETVGGyczisiabIeCu0vYJExjfkCrPLyYMlZSnEZLdY3CDAmSjEtRC8kh3wiqw X-Received: by 2002:a17:906:7a1c:: with SMTP id d28mr7253237ejo.10.1590607136854; Wed, 27 May 2020 12:18:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590607136; cv=none; d=google.com; s=arc-20160816; b=Zsr1YBsnbN3BHdn4Se1k3XZ6byIIbmHasjp15DK8/3iq5GTReaaPgUvB0ivtjux8ua t0zd+prFM7nMP5LAldBCBmNXchpCr4qLe/I2EzEfl4PGAyroUTiJiuWx6O+x/hG+TFG6 T6F7Ml0X8cpgt9IpzrTTqh6T04DhSGQy3Ts3fA9QFMPTPLjgsR5t84Q7gAlVebRI9MOX D3QRQrtnJWLgthIuOvoPghYhLdYue/S2K3r7p+GaV1rOWfNWnmjU7S0OzH7ILJxBiNPa ZWrIYL3inRBj1a3v2qau5aXzPipzVHMLQMfXR7Y0MJuH8D33Yj48JtwUI9hO6hd3ApHp z2Eg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=DUv0qmSITA7tWkheCbWB5KAR6Iy3Hgdb9QoxL9wLic8=; b=VFVZW8HUgot/IS7EOrRmKxFBzxWBJz/0wnxZZEhV+KfcgoXhQmfkQLuKVMfY4NCrYK bLiYdOW+I0W2bzl+DwpNP+avJrz1nZFCuK/bkKhfzuKHC+/R7wIjxU5v7tf98MDk1Loi /JSlZ+2sxc0nYhAh47Y1MACvXmIYO2a0lWdblvYecKYFryX1R70WdMy6t0l7YDLGDGmp mJSjESAvF/TKvCQcx80LDg+9lYTYVWD2wsQ11m81cztcQpSgBpbo00mT3s7Ri3Bw4T9N Xrpk+qRI10D2rIX8SPF5faamdfiZcbIEt5JwO0Z2vnHsceVuDvcow+77DV57u5ITBcJZ YREQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g31si2112854edd.232.2020.05.27.12.18.34; Wed, 27 May 2020 12:18:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728081AbgE0RaV (ORCPT + 98 others); Wed, 27 May 2020 13:30:21 -0400 Received: from foss.arm.com ([217.140.110.172]:42900 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726487AbgE0RaU (ORCPT ); Wed, 27 May 2020 13:30:20 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F0DCB31B; Wed, 27 May 2020 10:30:19 -0700 (PDT) Received: from [10.57.2.168] (unknown [10.57.2.168]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0D2B73F305; Wed, 27 May 2020 10:30:17 -0700 (PDT) Subject: Re: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address To: Srinath Mannam , Will Deacon , Joerg Roedel Cc: bcm-kernel-feedback-list@broadcom.com, linux-arm-kernel@lists.infradead.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Eric Auger , Alex Williamson , Jean-Philippe Brucker References: <1590595398-4217-1-git-send-email-srinath.mannam@broadcom.com> From: Robin Murphy Message-ID: Date: Wed, 27 May 2020 18:30:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <1590595398-4217-1-git-send-email-srinath.mannam@broadcom.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-05-27 17:03, Srinath Mannam wrote: > This patch gives the provision to change default value of MSI IOVA base > to platform's suitable IOVA using module parameter. The present > hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform. That in itself doesn't seem entirely unreasonable; IIRC the current address is just an arbitrary choice to fit nicely into Qemu's memory map, and there was always the possibility that it wouldn't suit everything. > Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible > DMA address"), inaccessible IOVA address ranges parsed from dma-ranges > property are reserved. That, however, doesn't seem to fit here; iommu-dma maps MSI doorbells dynamically, so they aren't affected by reserved regions any more than regular DMA pages are. In fact, it explicitly ignores the software MSI region, since as the comment says, it *is* the software that manages those. The MSI_IOVA_BASE region exists for VFIO, precisely because in that case the kernel *doesn't* control the address space, but still needs some way to steal a bit of it for MSIs that the guest doesn't necessarily know about, and give userspace a fighting chance of knowing what it's taken. I think at the time we discussed the idea of adding something to the VFIO uapi such that userspace could move this around if it wanted or needed to, but decided we could live without that initially. Perhaps now the time has come? Robin. > If any platform has the limitaion to access default MSI IOVA, then it can > be changed using "arm-smmu.msi_iova_base=0xa0000000" command line argument. > > Signed-off-by: Srinath Mannam > --- > drivers/iommu/arm-smmu.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c > index 4f1a350..5e59c9d 100644 > --- a/drivers/iommu/arm-smmu.c > +++ b/drivers/iommu/arm-smmu.c > @@ -72,6 +72,9 @@ static bool disable_bypass = > module_param(disable_bypass, bool, S_IRUGO); > MODULE_PARM_DESC(disable_bypass, > "Disable bypass streams such that incoming transactions from devices that are not attached to an iommu domain will report an abort back to the device and will not be allowed to pass through the SMMU."); > +static unsigned long msi_iova_base = MSI_IOVA_BASE; > +module_param(msi_iova_base, ulong, S_IRUGO); > +MODULE_PARM_DESC(msi_iova_base, "msi iova base address."); > > struct arm_smmu_s2cr { > struct iommu_group *group; > @@ -1566,7 +1569,7 @@ static void arm_smmu_get_resv_regions(struct device *dev, > struct iommu_resv_region *region; > int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO; > > - region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH, > + region = iommu_alloc_resv_region(msi_iova_base, MSI_IOVA_LENGTH, > prot, IOMMU_RESV_SW_MSI); > if (!region) > return; >