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 CBA1CC433F5 for ; Fri, 18 Mar 2022 13:25:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236660AbiCRN0e (ORCPT ); Fri, 18 Mar 2022 09:26:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236648AbiCRN03 (ORCPT ); Fri, 18 Mar 2022 09:26:29 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BDEC1EE4C6; Fri, 18 Mar 2022 06:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647609910; x=1679145910; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=InZ4gM0n9VmGhsbv3r77oTtxNorS/SN0pEblK/FfVAI=; b=ALEkEIPVvrMuPq9Hkd/lNYdyhk8o3wIj0iHIwgmxSfAixOeo1/OKHzys x/HwZKKrJWRw3db0q1I6XeeQgbAF2ijthPqRFxrExPdbyVnxNH8uTdKNI ZvFYXulTHPpNgZ5o5arUpGBaVmAU1Xx4SW0UPNRQU9dLy7TfoT10+nS2t InAWXY7HxeywHG6Y8148WVy+gOeMFJKy8f18JgAtm2M1s/hj78jUGhakZ gcCJvPG1ZJ3Tn4I3vwdp86GKbSHBgB3UG+Nj6xBtndHWU/slqVbg3NK1v Bn++0lVWxIwfz8/u7LfQCeKl67RvEr6Lu4r4XiASvi/0TJ6WOrwMyJzZ0 A==; X-IronPort-AV: E=McAfee;i="6200,9189,10289"; a="237745360" X-IronPort-AV: E=Sophos;i="5.90,192,1643702400"; d="scan'208";a="237745360" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2022 06:25:10 -0700 X-IronPort-AV: E=Sophos;i="5.90,192,1643702400"; d="scan'208";a="558438415" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.162]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2022 06:25:07 -0700 Received: by lahna (sSMTP sendmail emulation); Fri, 18 Mar 2022 15:25:04 +0200 Date: Fri, 18 Mar 2022 15:25:04 +0200 From: "mika.westerberg@linux.intel.com" To: Robin Murphy Cc: "Limonciello, Mario" , "andreas.noever@gmail.com" , "michael.jamet@intel.com" , "YehezkelShB@gmail.com" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "linux-pci@vger.kernel.org" Subject: Re: [PATCH] thunderbolt: Make iommu_dma_protection more accurate Message-ID: References: <2d01fa50c2650c730b0244929097737918e302e7.1647533152.git.robin.murphy@arm.com> <65207fdf-c4ab-5165-dbda-8ab55b51adb7@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65207fdf-c4ab-5165-dbda-8ab55b51adb7@arm.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robin, On Fri, Mar 18, 2022 at 12:01:42PM +0000, Robin Murphy wrote: > > This adds quite a lot code and complexity, and honestly I would like to > > keep it as simple as possible (and this is not enough because we need to > > make sure the DMAR bit is there so that none of the possible connected > > devices were able to overwrite our memory already). > > Shall we forget the standalone sibling check and just make the > pdev->untrusted check directly in tb_acpi_add_link() then? I think we should leave tb_acpi_add_link() untouched if possible ;-) This is because it is used to add the device links from firmware description that we need for proper power management of the tunneled devices. It has little to do with the identification of the external facing DMA-capable PCIe ports. Furthermore these links only exists in USB4 software connection manager systems so we do not have those in the existing Thunderbolt 3/4 systems that use firmware based connection manager (pretty much all out there). > On reflection I guess the DMAR bit makes iommu_dma_protection > functionally dependent on ACPI already, so we don't actually lose > anything (and anyone can come back and revisit firmware-agnostic > methods later if a need appears). I agree.