From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BA477C433F5 for ; Tue, 25 Jan 2022 19:32:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kpJLHxvLRJ5Grv3IxJHNQxPnH5v/kSCEWMWxy4dZsUc=; b=XOuz304/6dUUSC ghrctH8ksJM+9kDmAKmv+tNdNN3KRakM8GYQ6f6ReNUYqDrK1pOVNvpmb1kVfSjgGyHpU/J0uwc+6 ZMbGdWaPobXRXt3ApTdwTBhnIljiwEemkiJtwWi53KBOYkNZOaMatojQS7Qlid/9NlYbUWhMn1ImE wvInA8tgFWvEQevpCcWB7iHuJbbJsxalyiYLYg2QpFnIRjzQ+hJfybPsUoxFRToI8hGoNKFJKSjv+ BGldAqNlNxCvDhNSrVFhwNzAzGk7YSoTp7E3LALJlWxCuAYtd8+7UB/qX4rhbWOWbg+OhfRjB1zRy L5x/F99orr24jyzAKzAw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCRWs-009KrW-HO; Tue, 25 Jan 2022 19:30:58 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCRWo-009Kqf-RF for linux-arm-kernel@lists.infradead.org; Tue, 25 Jan 2022 19:30:56 +0000 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 788AC1FB; Tue, 25 Jan 2022 11:30:51 -0800 (PST) Received: from [10.57.68.26] (unknown [10.57.68.26]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4C5BD3F7D8; Tue, 25 Jan 2022 11:30:49 -0800 (PST) Message-ID: <93374408-9522-8648-3417-0d8750d652bb@arm.com> Date: Tue, 25 Jan 2022 19:30:43 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v7 0/9] ACPI/IORT: Support for IORT RMR node Content-Language: en-GB To: Shameerali Kolothum Thodi , "linux-arm-kernel@lists.infradead.org" , "linux-acpi@vger.kernel.org" , "iommu@lists.linux-foundation.org" Cc: Lorenzo Pieralisi , "jon@solid-run.com" , Linuxarm , "steven.price@arm.com" , "Guohanjun (Hanjun Guo)" , yangyicong , "Sami.Mujawar@arm.com" , "will@kernel.org" , wanghuiqiang , "eric.auger@redhat.com" , Laurentiu Tudor References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <9da65c2504b944398188e468eac1abff@huawei.com> From: Robin Murphy In-Reply-To: <9da65c2504b944398188e468eac1abff@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220125_113055_014414_7FC6FD16 X-CRM114-Status: GOOD ( 26.47 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-01-25 13:00, Shameerali Kolothum Thodi wrote: > Hi Robin/Lorenzo, > >> -----Original Message----- >> From: iommu [mailto:iommu-bounces@lists.linux-foundation.org] On Behalf >> Of Shameer Kolothum >> Sent: 05 August 2021 09:07 >> To: linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; >> iommu@lists.linux-foundation.org >> Cc: robin.murphy@arm.com; jon@solid-run.com; Linuxarm >> ; steven.price@arm.com; Guohanjun (Hanjun Guo) >> ; yangyicong ; >> Sami.Mujawar@arm.com; will@kernel.org; wanghuiqiang >> >> Subject: [PATCH v7 0/9] ACPI/IORT: Support for IORT RMR node >> >> Hi, >> >> The series adds support to IORT RMR nodes specified in IORT >> Revision E.b -ARM DEN 0049E[0]. RMR nodes are used to describe >> memory ranges that are used by endpoints and require a unity >> mapping in SMMU. >> >> We have faced issues with 3408iMR RAID controller cards which >> fail to boot when SMMU is enabled. This is because these >> controllers make use of host memory for various caching related >> purposes and when SMMU is enabled the iMR firmware fails to >> access these memory regions as there is no mapping for them. >> IORT RMR provides a way for UEFI to describe and report these >> memory regions so that the kernel can make a unity mapping for >> these in SMMU. >> >> Change History: >> >> v6 --> v7 >> >> The only change from v6 is the fix pointed out by Steve to >> the SMMUv2 SMR bypass install in patch #8. >> >> Thanks to the Tested-by tags by Laurentiu with SMMUv2 and >> Hanjun/Huiqiang with SMMUv3 for v6. I haven't added the tags >> yet as the series still needs more review[1]. >> >> Feedback and tests on this series is very much appreciated. > > Since we have an update to IORT spec(E.c) now[1] and includes additional > attributes/flags for the RMR node, I am planning to respin this series soon. > > Going through the new spec, I have a few queries, > > The memory range attributes can now be described as one of the following, > > 0x00: Device-nGnRnE memory > 0x01: Device-nGnRE memory > 0x02: Device-nGRE memory > 0x03: Device-GRE memory > 0x04: Normal Inner Non-cacheable Outer Non-cacheable > 0x05: Normal Inner Write-back Outer Write-back Inner Shareable > > I am not sure how this needs to be captured and used in the kernel. Is there > any intention of using these fine-grained attributes in the kernel now > or a generic mapping of the above to the struct iommu_rev_region prot field > is enough? i.e., something like, > > { > .... > prot = IOMMU_READ | IOMMU_WRITE; > > if (rmr_attr == normal_mem) // 0x05 > prot |= IOMMU_CACHE; > > if (rmr_attr == device_mem) { //0x00 - 0x03 > prot |= IOMMU_MMIO; > prot |= IOMMU_NOEXEC; > } > .... > } Yup, pretty much that, except don't bother with IOMMU_NOEXEC. We can't reliably infer it - e.g. on an AXI-based interconnect AxCACHE and AxPROT are entirely orthogonal, so a Device-type read with the "Instruction access" hint is perfectly legal - and in the common IORT code we're not in a position to second-guess what any given RMR might represent for whatever agent is accessing it. All we can reasonably do here is map the Device types to IOMMU_MMIO and Write-back to IOMMU_CACHE, and if anyone ever does want to insist that that's not sufficient, then they're welcome to send patches to make the IOMMU API more expressive :) > Similarly for the 'flags' field, the new 'Access Privilege' is intended to set the > IOMMU_PRIV ? Yes, exactly! Cheers, Robin. > > Please let me know. > > Thanks, > Shameer > > [1] https://developer.arm.com/documentation/den0049/ec/?lang=en > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel