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 0CBEEC433FE for ; Tue, 15 Mar 2022 18:08:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350984AbiCOSJM (ORCPT ); Tue, 15 Mar 2022 14:09:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350970AbiCOSJI (ORCPT ); Tue, 15 Mar 2022 14:09:08 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 94A0F6373; Tue, 15 Mar 2022 11:07:54 -0700 (PDT) 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 0A3A41474; Tue, 15 Mar 2022 11:07:54 -0700 (PDT) Received: from [10.57.42.204] (unknown [10.57.42.204]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6B68B3F73D; Tue, 15 Mar 2022 11:07:52 -0700 (PDT) Message-ID: <21d33a75-8c0e-7734-b3d1-dbe33cfe0ab0@arm.com> Date: Tue, 15 Mar 2022 18:07:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH 2/2] thunderbolt: Use pre-boot DMA protection on AMD systems Content-Language: en-GB To: "Limonciello, Mario" , Christoph Hellwig Cc: Michael Jamet , Mika Westerberg , "open list:THUNDERBOLT DRIVER" , open list , Yehezkel Bernat , "open list:AMD IOMMU (AMD-VI)" , Andreas Noever , Will Deacon References: <20220315162455.5190-1-mario.limonciello@amd.com> <20220315162455.5190-2-mario.limonciello@amd.com> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-03-15 16:54, Limonciello, Mario via iommu wrote: > [Public] > > >> On Tue, Mar 15, 2022 at 11:24:55AM -0500, Mario Limonciello wrote: >>> - * handled natively using IOMMU. It is enabled when IOMMU is >>> - * enabled and ACPI DMAR table has DMAR_PLATFORM_OPT_IN set. >>> + * handled natively using IOMMU. It is enabled when the IOMMU is >>> + * enabled and either: >>> + * ACPI DMAR table has DMAR_PLATFORM_OPT_IN set >>> + * or >>> + * ACPI IVRS table has DMA_REMAP bitset >>> */ >>> return sprintf(buf, "%d\n", >>> - iommu_present(&pci_bus_type) && >> dmar_platform_optin()); >>> + iommu_present(&pci_bus_type) && >>> + (dmar_platform_optin() || amd_ivrs_remap_support())); >> >> Yikes. No, the thunderbot code does not have any business poking into >> either dmar_platform_optin or amd_ivrs_remap_support. This needs >> a proper abstration from the IOMMU code. > > To make sure I follow your ask - it's to make a new generic iommu function > That would check dmar/ivrs, and switch out thunderbolt domain.c to use the > symbol? > > I'm happy to rework that if that is what you want. > Do you have a preferred proposed function name for that? But why? Either IOMMU translation is enabled or it isn't, and if it is, what's to gain from guessing at *why* it might have been? And even if the IOMMU's firmware table did tell the IOMMU driver to enable the IOMMU, why should that be Thunderbolt's business? Furthermore, looking at patch #1 I can only conclude that this is entirely meaningless anyway. AFAICS it's literally reporting whether the firmware flag was set or not. Not whether it's actually been honoured and the IOMMU is enforcing any kind of DMA protection at all. Even on Intel where the flag does at least have some effect on the IOMMU driver, that can still be overridden. I already have a patch refactoring this to get rid of iommu_present(), but at the time I wasn't looking to closely at what it's trying to *do* with the information. If it's supposed to accurately reflect whether the Thunderbolt device is subject to IOMMU translation and not bypassed, I can fix that too (and unexport dmar_platform_optin() in the process...) 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 smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (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 B1A1CC433F5 for ; Tue, 15 Mar 2022 18:07:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5086C4170D; Tue, 15 Mar 2022 18:07:58 +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 R0wC7G4uw8gg; Tue, 15 Mar 2022 18:07:57 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp4.osuosl.org (Postfix) with ESMTPS id 40B8141701; Tue, 15 Mar 2022 18:07:57 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1752FC0012; Tue, 15 Mar 2022 18:07:57 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4A83FC000B for ; Tue, 15 Mar 2022 18:07:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 23F3540217 for ; Tue, 15 Mar 2022 18:07:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNgRdVlxP5AQ for ; Tue, 15 Mar 2022 18:07:54 +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 smtp2.osuosl.org (Postfix) with ESMTP id CFE6F400D1 for ; Tue, 15 Mar 2022 18:07:54 +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 0A3A41474; Tue, 15 Mar 2022 11:07:54 -0700 (PDT) Received: from [10.57.42.204] (unknown [10.57.42.204]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6B68B3F73D; Tue, 15 Mar 2022 11:07:52 -0700 (PDT) Message-ID: <21d33a75-8c0e-7734-b3d1-dbe33cfe0ab0@arm.com> Date: Tue, 15 Mar 2022 18:07:47 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH 2/2] thunderbolt: Use pre-boot DMA protection on AMD systems Content-Language: en-GB To: "Limonciello, Mario" , Christoph Hellwig References: <20220315162455.5190-1-mario.limonciello@amd.com> <20220315162455.5190-2-mario.limonciello@amd.com> From: Robin Murphy In-Reply-To: Cc: Michael Jamet , Will Deacon , "open list:THUNDERBOLT DRIVER" , open list , Andreas Noever , "open list:AMD IOMMU \(AMD-VI\)" , Yehezkel Bernat , Mika Westerberg 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 2022-03-15 16:54, Limonciello, Mario via iommu wrote: > [Public] > > >> On Tue, Mar 15, 2022 at 11:24:55AM -0500, Mario Limonciello wrote: >>> - * handled natively using IOMMU. It is enabled when IOMMU is >>> - * enabled and ACPI DMAR table has DMAR_PLATFORM_OPT_IN set. >>> + * handled natively using IOMMU. It is enabled when the IOMMU is >>> + * enabled and either: >>> + * ACPI DMAR table has DMAR_PLATFORM_OPT_IN set >>> + * or >>> + * ACPI IVRS table has DMA_REMAP bitset >>> */ >>> return sprintf(buf, "%d\n", >>> - iommu_present(&pci_bus_type) && >> dmar_platform_optin()); >>> + iommu_present(&pci_bus_type) && >>> + (dmar_platform_optin() || amd_ivrs_remap_support())); >> >> Yikes. No, the thunderbot code does not have any business poking into >> either dmar_platform_optin or amd_ivrs_remap_support. This needs >> a proper abstration from the IOMMU code. > > To make sure I follow your ask - it's to make a new generic iommu function > That would check dmar/ivrs, and switch out thunderbolt domain.c to use the > symbol? > > I'm happy to rework that if that is what you want. > Do you have a preferred proposed function name for that? But why? Either IOMMU translation is enabled or it isn't, and if it is, what's to gain from guessing at *why* it might have been? And even if the IOMMU's firmware table did tell the IOMMU driver to enable the IOMMU, why should that be Thunderbolt's business? Furthermore, looking at patch #1 I can only conclude that this is entirely meaningless anyway. AFAICS it's literally reporting whether the firmware flag was set or not. Not whether it's actually been honoured and the IOMMU is enforcing any kind of DMA protection at all. Even on Intel where the flag does at least have some effect on the IOMMU driver, that can still be overridden. I already have a patch refactoring this to get rid of iommu_present(), but at the time I wasn't looking to closely at what it's trying to *do* with the information. If it's supposed to accurately reflect whether the Thunderbolt device is subject to IOMMU translation and not bypassed, I can fix that too (and unexport dmar_platform_optin() in the process...) Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu