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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F262C433EF for ; Wed, 8 Dec 2021 12:19:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229767AbhLHMWe (ORCPT ); Wed, 8 Dec 2021 07:22:34 -0500 Received: from foss.arm.com ([217.140.110.172]:58542 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233240AbhLHMWe (ORCPT ); Wed, 8 Dec 2021 07:22:34 -0500 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 885C81042; Wed, 8 Dec 2021 04:19:02 -0800 (PST) Received: from e123427-lin.cambridge.arm.com (unknown [10.57.36.149]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D4DB33F73B; Wed, 8 Dec 2021 04:18:59 -0800 (PST) Date: Wed, 8 Dec 2021 12:18:54 +0000 From: Lorenzo Pieralisi To: Jon Nettleton Cc: Robin Murphy , Shameer Kolothum , linux-arm-kernel , ACPI Devel Maling List , Linux IOMMU , Linuxarm , Steven Price , Hanjun Guo , yangyicong , Sami Mujawar , Will Deacon , wanghuiqiang Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Message-ID: <20211208121854.GA7317@e123427-lin.cambridge.arm.com> References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> <3225875e-ebd9-6378-e92c-ed3894d8aedc@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Tue, Oct 12, 2021 at 10:00:24AM +0200, Jon Nettleton wrote: > On Mon, Oct 11, 2021 at 4:04 PM Robin Murphy wrote: > > > > 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". > > Ultimately the spec doesn't mention what IOMMU properties the regions > should have. It will have to and that's what we are working on. > Even marking them as IOMMU_READ/WRITE is as much of an assumption as > using IOMMU_MMIO or IOMMU_CACHE. It just seems IOMMU_MMIO is the most > popular since all the examples use it for MSI doorbells in the > documentation. We don't merge code based on assumptions that can easily break because the specifications don't contemplate the details that are required. > I am interested why this concern is only being brought up at this point > on a patchset that has been on the mailing list for 8+ months? See above. We don't merge code that we know can break and is based on assumptions, we need to update the IORT specifications to make them cover all the use cases - in a predictable way - and that's what we are working on. > This is based on a spec that has existed from Arm since 2020 with the > most recent revisions published in Feb 2021. The lack of RMR support > in the kernel is affecting real world products, and the ability for > SystemReady ES certified systems from just fully working with recent > distributions. I answered above - if you have any questions please ask them, here, as far as Linux code is concerned. I understand this is taking a long time, it is also helping us understand all the possible use cases and how to cover them in a way that is maintainable in the long run. Thanks, Lorenzo > Even worse, is that without this patchset customers are forced to jump > through hoops to purposefully re-enable smmu bypass making their > systems less secure. > > How is this a good experience for customers of SystemReady hardware > when for any mainline distribution to work the first thing they have > to do is make their system less secure? > > -Jon > > > > > Thanks, > > Robin. > 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 8A890C433F5 for ; Wed, 8 Dec 2021 12:19:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3726382897; Wed, 8 Dec 2021 12:19:08 +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 IlSvXURm25rW; Wed, 8 Dec 2021 12:19:07 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp1.osuosl.org (Postfix) with ESMTPS id 1D40282B08; Wed, 8 Dec 2021 12:19:06 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 02752C001E; Wed, 8 Dec 2021 12:19:06 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 65D60C0012 for ; Wed, 8 Dec 2021 12:19:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 54B3D41D93 for ; Wed, 8 Dec 2021 12:19:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4glHvR7zoxyk for ; Wed, 8 Dec 2021 12:19:03 +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 smtp4.osuosl.org (Postfix) with ESMTP id 441D841CC5 for ; Wed, 8 Dec 2021 12:19:03 +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 885C81042; Wed, 8 Dec 2021 04:19:02 -0800 (PST) Received: from e123427-lin.cambridge.arm.com (unknown [10.57.36.149]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D4DB33F73B; Wed, 8 Dec 2021 04:18:59 -0800 (PST) Date: Wed, 8 Dec 2021 12:18:54 +0000 From: Lorenzo Pieralisi To: Jon Nettleton Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Message-ID: <20211208121854.GA7317@e123427-lin.cambridge.arm.com> References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> <3225875e-ebd9-6378-e92c-ed3894d8aedc@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Cc: Will Deacon , Linuxarm , Steven Price , ACPI Devel Maling List , Linux IOMMU , wanghuiqiang , Hanjun Guo , yangyicong , Sami Mujawar , Robin Murphy , 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Tue, Oct 12, 2021 at 10:00:24AM +0200, Jon Nettleton wrote: > On Mon, Oct 11, 2021 at 4:04 PM Robin Murphy wrote: > > > > 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". > > Ultimately the spec doesn't mention what IOMMU properties the regions > should have. It will have to and that's what we are working on. > Even marking them as IOMMU_READ/WRITE is as much of an assumption as > using IOMMU_MMIO or IOMMU_CACHE. It just seems IOMMU_MMIO is the most > popular since all the examples use it for MSI doorbells in the > documentation. We don't merge code based on assumptions that can easily break because the specifications don't contemplate the details that are required. > I am interested why this concern is only being brought up at this point > on a patchset that has been on the mailing list for 8+ months? See above. We don't merge code that we know can break and is based on assumptions, we need to update the IORT specifications to make them cover all the use cases - in a predictable way - and that's what we are working on. > This is based on a spec that has existed from Arm since 2020 with the > most recent revisions published in Feb 2021. The lack of RMR support > in the kernel is affecting real world products, and the ability for > SystemReady ES certified systems from just fully working with recent > distributions. I answered above - if you have any questions please ask them, here, as far as Linux code is concerned. I understand this is taking a long time, it is also helping us understand all the possible use cases and how to cover them in a way that is maintainable in the long run. Thanks, Lorenzo > Even worse, is that without this patchset customers are forced to jump > through hoops to purposefully re-enable smmu bypass making their > systems less secure. > > How is this a good experience for customers of SystemReady hardware > when for any mainline distribution to work the first thing they have > to do is make their system less secure? > > -Jon > > > > > 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 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 10CEFC433EF for ; Wed, 8 Dec 2021 12:20:41 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Kbbem8JLrE5hyjmv2mfVRAzvPvoFAOwz6D31M0EdTTw=; b=c0U12OpIyLHwqY V+u3VlAbU/dUIbcUFJklLWjkPx8RPuLpGUzBGBdLMwGcvCZTp65JJfT0LFXp/XoMRu2swUR9yircv YZb1EtQUPmWy0soN7AAi+G9HjbZDK12kQJvGPijFEbz6IDsdSkJ6D1Osg7R7DwNZ02zYtYkhGSjYb 8x++k9Nv+3X3vmJ1SuouOAHUF46NAvXw+brV9Hh6q6rkG4sFDamX+HNu0KAT53DaCYTZ84X+U7xt0 NWl3j3cMfxT34JL75Ih+hU0Ca/6PU0C2+X036lBsZziIS0iHH85Y7PxJI0GZd7NIUWt6dfnxGLLcq Grybb82tp5BehfVvWX/w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1muvuc-00CRm9-W7; Wed, 08 Dec 2021 12:19:07 +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 1muvuZ-00CRlk-Cu for linux-arm-kernel@lists.infradead.org; Wed, 08 Dec 2021 12:19:05 +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 885C81042; Wed, 8 Dec 2021 04:19:02 -0800 (PST) Received: from e123427-lin.cambridge.arm.com (unknown [10.57.36.149]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D4DB33F73B; Wed, 8 Dec 2021 04:18:59 -0800 (PST) Date: Wed, 8 Dec 2021 12:18:54 +0000 From: Lorenzo Pieralisi To: Jon Nettleton Cc: Robin Murphy , Shameer Kolothum , linux-arm-kernel , ACPI Devel Maling List , Linux IOMMU , Linuxarm , Steven Price , Hanjun Guo , yangyicong , Sami Mujawar , Will Deacon , wanghuiqiang Subject: Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing Message-ID: <20211208121854.GA7317@e123427-lin.cambridge.arm.com> References: <20210805080724.480-1-shameerali.kolothum.thodi@huawei.com> <20210805080724.480-3-shameerali.kolothum.thodi@huawei.com> <3225875e-ebd9-6378-e92c-ed3894d8aedc@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211208_041903_563567_653EF64D X-CRM114-Status: GOOD ( 41.11 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Oct 12, 2021 at 10:00:24AM +0200, Jon Nettleton wrote: > On Mon, Oct 11, 2021 at 4:04 PM Robin Murphy wrote: > > > > 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". > > Ultimately the spec doesn't mention what IOMMU properties the regions > should have. It will have to and that's what we are working on. > Even marking them as IOMMU_READ/WRITE is as much of an assumption as > using IOMMU_MMIO or IOMMU_CACHE. It just seems IOMMU_MMIO is the most > popular since all the examples use it for MSI doorbells in the > documentation. We don't merge code based on assumptions that can easily break because the specifications don't contemplate the details that are required. > I am interested why this concern is only being brought up at this point > on a patchset that has been on the mailing list for 8+ months? See above. We don't merge code that we know can break and is based on assumptions, we need to update the IORT specifications to make them cover all the use cases - in a predictable way - and that's what we are working on. > This is based on a spec that has existed from Arm since 2020 with the > most recent revisions published in Feb 2021. The lack of RMR support > in the kernel is affecting real world products, and the ability for > SystemReady ES certified systems from just fully working with recent > distributions. I answered above - if you have any questions please ask them, here, as far as Linux code is concerned. I understand this is taking a long time, it is also helping us understand all the possible use cases and how to cover them in a way that is maintainable in the long run. Thanks, Lorenzo > Even worse, is that without this patchset customers are forced to jump > through hoops to purposefully re-enable smmu bypass making their > systems less secure. > > How is this a good experience for customers of SystemReady hardware > when for any mainline distribution to work the first thing they have > to do is make their system less secure? > > -Jon > > > > > Thanks, > > Robin. > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel