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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 43FB8C433EF for ; Mon, 11 Oct 2021 14:04:15 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E192D6128C for ; Mon, 11 Oct 2021 14:04:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E192D6128C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9970780E8F; Mon, 11 Oct 2021 14:04:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gt_2vsxSdkT; Mon, 11 Oct 2021 14:04:13 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6A05380E62; Mon, 11 Oct 2021 14:04:13 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3D6B7C000F; Mon, 11 Oct 2021 14:04:13 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 426ECC000D for ; Mon, 11 Oct 2021 14:04:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 180AE6071E for ; Mon, 11 Oct 2021 14:04:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR6aGrsw2iLV for ; Mon, 11 Oct 2021 14:04:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp3.osuosl.org (Postfix) with ESMTP id 62D756068D for ; Mon, 11 Oct 2021 14:04:10 +0000 (UTC) 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 9A6A4101E; Mon, 11 Oct 2021 07:04:09 -0700 (PDT) Received: from [10.57.95.157] (unknown [10.57.95.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BB0BD3F694; Mon, 11 Oct 2021 07:04:07 -0700 (PDT) Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing To: Jon Nettleton References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> From: Robin Murphy Message-ID: <3225875e-ebd9-6378-e92c-ed3894d8aedc@arm.com> Date: Mon, 11 Oct 2021 15:04:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB Cc: Linuxarm , Steven Price , ACPI Devel Maling List , Linux IOMMU , wanghuiqiang , Hanjun Guo , yangyicong , Sami Mujawar , Will Deacon , linux-arm-kernel X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2021-10-09 08:06, Jon Nettleton wrote: [...] >>> + if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) { >>> + type = IOMMU_RESV_DIRECT_RELAXABLE; >>> + /* >>> + * Set IOMMU_CACHE as IOMMU_RESV_DIRECT_RELAXABLE is >>> + * normally used for allocated system memory that is >>> + * then used for device specific reserved regions. >>> + */ >>> + prot |= IOMMU_CACHE; >>> + } else { >>> + type = IOMMU_RESV_DIRECT; >>> + /* >>> + * Set IOMMU_MMIO as IOMMU_RESV_DIRECT is normally used >>> + * for device memory like MSI doorbell. >>> + */ >>> + prot |= IOMMU_MMIO; >>> + } >> >> I'm not sure we ever got a definitive answer to this - does DPAA2 >> actually go wrong if we use IOMMU_MMIO here? I'd still much prefer to >> make the fewest possible assumptions, since at this point it's basically >> just a stop-gap until we can fix the spec. It's become clear that we >> can't reliably rely on guessing attributes, so I'm not too fussed about >> theoretical cases that currently don't work (due to complete lack of RMR >> support) continuing to not work for the moment, as long as we can make >> the real-world cases we actually have work at all. Anything which only >> affects performance I'd rather leave until firmware can tell us what to do. > > Well it isn't DPAA2, it is FSL_MC_BUS that fails with IOMMU_MMIO > mappings. DPAA2 is just one connected device. Apologies if I'm being overly loose with terminology there - my point of reference for this hardware is documentation for the old LS2080A, where the "DPAA2 Reference Manual" gives a strong impression that the MC is a component belonging to the overall DPAA2 architecture. Either way it technically stands to reason that the other DPAA2 components would only be usable if the MC itself works (unless I've been holding a major misconception about that for years as well). In the context of this discussion, please consider any reference I may make to bits of NXP's hardware to be shorthand for "the thing for which NXP have a vested interest in IORT RMRs". Thanks, Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A16B5C433FE for ; Mon, 11 Oct 2021 14:05:34 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 7802A60F4B for ; Mon, 11 Oct 2021 14:05:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7802A60F4B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Qitl7R5DHc6fxxynezTFT1pfs7z9zEIqXsLGfbEKRmk=; b=VFM3WiWghv8scY6FyS47AMKxM5 dDvus1/VWei3BVAh1vOPYnws0zP4zd4e0Qgphy+If0IoqtXdWJDVQiTorMR+4k+z5+Eb7buTH3/GP CC0gvah7DIyYoI3f6OyEtHaoeo3N1B4opZwU7s5anNuT7eGxvJu6TFxrwvQGUuhrntOZN2ExG92AO vKOL5LpEgR3RBsClSJXJ5GRKiPYxx05ICYH6Ng9US8RVSeS3PQdy7kRKHQspIbT/wYM59ccjKcb/7 +hz57E9igGAnp9gqzK8KqHu0urFSbNsVdy6vpD2ovRJ8dklyHcWIBYD2ifS0JtR0eNwi8oDqbW36Q Fks+99sQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mZvua-009hyY-J6; Mon, 11 Oct 2021 14:04:16 +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 1mZvuX-009hxT-7P for linux-arm-kernel@lists.infradead.org; Mon, 11 Oct 2021 14:04:14 +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 9A6A4101E; Mon, 11 Oct 2021 07:04:09 -0700 (PDT) Received: from [10.57.95.157] (unknown [10.57.95.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BB0BD3F694; Mon, 11 Oct 2021 07:04:07 -0700 (PDT) Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing To: Jon Nettleton Cc: Shameer Kolothum , linux-arm-kernel , ACPI Devel Maling List , Linux IOMMU , Linuxarm , Steven Price , Hanjun Guo , yangyicong , Sami Mujawar , Will Deacon , wanghuiqiang References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> From: Robin Murphy Message-ID: <3225875e-ebd9-6378-e92c-ed3894d8aedc@arm.com> Date: Mon, 11 Oct 2021 15:04:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211011_070413_346079_13BB1BC9 X-CRM114-Status: GOOD ( 17.62 ) 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 2021-10-09 08:06, Jon Nettleton wrote: [...] >>> + if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) { >>> + type = IOMMU_RESV_DIRECT_RELAXABLE; >>> + /* >>> + * Set IOMMU_CACHE as IOMMU_RESV_DIRECT_RELAXABLE is >>> + * normally used for allocated system memory that is >>> + * then used for device specific reserved regions. >>> + */ >>> + prot |= IOMMU_CACHE; >>> + } else { >>> + type = IOMMU_RESV_DIRECT; >>> + /* >>> + * Set IOMMU_MMIO as IOMMU_RESV_DIRECT is normally used >>> + * for device memory like MSI doorbell. >>> + */ >>> + prot |= IOMMU_MMIO; >>> + } >> >> I'm not sure we ever got a definitive answer to this - does DPAA2 >> actually go wrong if we use IOMMU_MMIO here? I'd still much prefer to >> make the fewest possible assumptions, since at this point it's basically >> just a stop-gap until we can fix the spec. It's become clear that we >> can't reliably rely on guessing attributes, so I'm not too fussed about >> theoretical cases that currently don't work (due to complete lack of RMR >> support) continuing to not work for the moment, as long as we can make >> the real-world cases we actually have work at all. Anything which only >> affects performance I'd rather leave until firmware can tell us what to do. > > Well it isn't DPAA2, it is FSL_MC_BUS that fails with IOMMU_MMIO > mappings. DPAA2 is just one connected device. Apologies if I'm being overly loose with terminology there - my point of reference for this hardware is documentation for the old LS2080A, where the "DPAA2 Reference Manual" gives a strong impression that the MC is a component belonging to the overall DPAA2 architecture. Either way it technically stands to reason that the other DPAA2 components would only be usable if the MC itself works (unless I've been holding a major misconception about that for years as well). In the context of this discussion, please consider any reference I may make to bits of NXP's hardware to be shorthand for "the thing for which NXP have a vested interest in IORT RMRs". Thanks, Robin. _______________________________________________ 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 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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07C72C433EF for ; Mon, 11 Oct 2021 14:06:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E5A5B6136F for ; Mon, 11 Oct 2021 14:06:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237804AbhJKOIL (ORCPT ); Mon, 11 Oct 2021 10:08:11 -0400 Received: from foss.arm.com ([217.140.110.172]:56870 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238654AbhJKOGN (ORCPT ); Mon, 11 Oct 2021 10:06:13 -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 9A6A4101E; Mon, 11 Oct 2021 07:04:09 -0700 (PDT) Received: from [10.57.95.157] (unknown [10.57.95.157]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BB0BD3F694; Mon, 11 Oct 2021 07:04:07 -0700 (PDT) Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing To: Jon Nettleton Cc: Shameer Kolothum , linux-arm-kernel , ACPI Devel Maling List , Linux IOMMU , Linuxarm , Steven Price , Hanjun Guo , yangyicong , Sami Mujawar , Will Deacon , wanghuiqiang References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> From: Robin Murphy Message-ID: <3225875e-ebd9-6378-e92c-ed3894d8aedc@arm.com> Date: Mon, 11 Oct 2021 15:04:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On 2021-10-09 08:06, Jon Nettleton wrote: [...] >>> + if (rmr->flags & IOMMU_RMR_REMAP_PERMITTED) { >>> + type = IOMMU_RESV_DIRECT_RELAXABLE; >>> + /* >>> + * Set IOMMU_CACHE as IOMMU_RESV_DIRECT_RELAXABLE is >>> + * normally used for allocated system memory that is >>> + * then used for device specific reserved regions. >>> + */ >>> + prot |= IOMMU_CACHE; >>> + } else { >>> + type = IOMMU_RESV_DIRECT; >>> + /* >>> + * Set IOMMU_MMIO as IOMMU_RESV_DIRECT is normally used >>> + * for device memory like MSI doorbell. >>> + */ >>> + prot |= IOMMU_MMIO; >>> + } >> >> I'm not sure we ever got a definitive answer to this - does DPAA2 >> actually go wrong if we use IOMMU_MMIO here? I'd still much prefer to >> make the fewest possible assumptions, since at this point it's basically >> just a stop-gap until we can fix the spec. It's become clear that we >> can't reliably rely on guessing attributes, so I'm not too fussed about >> theoretical cases that currently don't work (due to complete lack of RMR >> support) continuing to not work for the moment, as long as we can make >> the real-world cases we actually have work at all. Anything which only >> affects performance I'd rather leave until firmware can tell us what to do. > > Well it isn't DPAA2, it is FSL_MC_BUS that fails with IOMMU_MMIO > mappings. DPAA2 is just one connected device. Apologies if I'm being overly loose with terminology there - my point of reference for this hardware is documentation for the old LS2080A, where the "DPAA2 Reference Manual" gives a strong impression that the MC is a component belonging to the overall DPAA2 architecture. Either way it technically stands to reason that the other DPAA2 components would only be usable if the MC itself works (unless I've been holding a major misconception about that for years as well). In the context of this discussion, please consider any reference I may make to bits of NXP's hardware to be shorthand for "the thing for which NXP have a vested interest in IORT RMRs". Thanks, Robin.