Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5248560imu; Tue, 13 Nov 2018 03:41:08 -0800 (PST) X-Google-Smtp-Source: AJdET5dAX8fudsmUVv1fAOZwjNogNEqHA/VC2292Y4f9HE0HYjYR8tjh2OUd25h17pDQ4dJV2xIN X-Received: by 2002:a63:2643:: with SMTP id m64mr4375199pgm.35.1542109268688; Tue, 13 Nov 2018 03:41:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542109268; cv=none; d=google.com; s=arc-20160816; b=1BK+2P/VOhGe4p9qS6QED6L0n+46itOJcZtScEIkFUltZK9w6KoPoqqmJE3PH2To/h EXaU2xMMNwUk3bsVdMBZfkSSKovwa2vK5Kod7unb7HLO9+PsuIXJob0FKfUn8vLMq+r9 A07LY4+vkTQercpUHOMlKNs67LxzAIG4Z/tAjAAuhaoQIsoOHTkuZfRxsmOhl7D+aXAO O+lr+Wz2URz/a68xNuFPySiuxXL6pamCFS6mIkQUQ/8xov0FcI1/qR41eOjDGZS58tmq IwZH0esbkUwZ9pT24joH9UY8WiVQkZHbRo4frOcFu6Bbxq24Ya301aLsXPQnxgmf/Bp1 e9Xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=rn+1cn/lgvfwQCD3K/ghestTsUmKr7kbuOCBa6xQPn8=; b=qRdC3rpH8SA6mM/e9tT+9hNDgksTCf42MfTN1L+Ta3ty3b1vUl6RCTLnrUEzPW3I8/ 6C1Crqks6XgYxDZK+0KV1nn+jJIQFHxsNHETKPPRvophTx90gfK+K8DQw90iMVRYUSmo DQyKn4laxcxR0sbnnR34+TpOXZT5WFebRmsyQ2c2r98e8GwBDCAh6fncGWlbXSsl5y65 3GNOzDl5EGGgy4LGYtz6F8bHb/iWEd3cpyrQSf7/bVY0LNpFuQ+rCoW4z2zqSWv4u1kP vhdltr3T3B36r94izHEaHOX5m5jzf+kkfgOtYU3puReZGPnqBvFN//bCRCOqXnOVji0y q/QQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g12si11215891pgd.567.2018.11.13.03.40.53; Tue, 13 Nov 2018 03:41:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732728AbeKMViM (ORCPT + 99 others); Tue, 13 Nov 2018 16:38:12 -0500 Received: from mga07.intel.com ([134.134.136.100]:62267 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732524AbeKMViL (ORCPT ); Tue, 13 Nov 2018 16:38:11 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2018 03:40:27 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,499,1534834800"; d="scan'208";a="249314799" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.157]) by orsmga004.jf.intel.com with SMTP; 13 Nov 2018 03:40:21 -0800 Received: by lahna (sSMTP sendmail emulation); Tue, 13 Nov 2018 13:40:20 +0200 Date: Tue, 13 Nov 2018 13:40:20 +0200 From: Mika Westerberg To: Yehezkel Bernat Cc: iommu@lists.linux-foundation.org, joro@8bytes.org, David Woodhouse , baolu.lu@linux.intel.com, ashok.raj@intel.com, Bjorn Helgaas , rjw@rjwysocki.net, jacob.jun.pan@intel.com, Andreas Noever , michael.jamet@intel.com, lukas@wunner.de, Christian Kellner , Mario Limonciello , Anthony Wong , linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, LKML Subject: Re: [PATCH 4/4] thunderbolt: Export IOMMU based DMA protection support to userspace Message-ID: <20181113114020.GV2500@lahna.fi.intel.com> References: <20181112160628.86620-1-mika.westerberg@linux.intel.com> <20181112160628.86620-5-mika.westerberg@linux.intel.com> <20181113105558.GR2500@lahna.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 13, 2018 at 01:13:31PM +0200, Yehezkel Bernat wrote: > On Tue, Nov 13, 2018 at 12:56 PM Mika Westerberg > wrote: > > > > > Just one point: > > > Have you considered the option to add this property per (TBT?) device? > > > > No. ;-) > > > > You mean that one device uses security levels and another IOMMU? I don't > > think it is possible without having some sort of table in the IOMMU > > driver telling which devices it needs identity map and which not. Also > > not sure what would be the benefit? > > For performance, of course. If some devices are considered safe (maybe a list > communicated by platform firmware), the kernel may decide to configure them to > passthrough the IOMMU (I think I remember there is such an option, but maybe I'm > wrong.) At least I'm not aware of such an option. Windows for example enables IOMMU for everything and I think macOS does the same. In Linux (with these patches) we put all internal devices already passthrough mode so things like internal graphics should not be affected. eGPUs are different thing, though. > > > If the kernel may decide to enable/disable the IOMMU or AST per device, maybe > > > it should be on this level. > > > Or maybe the IOMMU decision isn't going to change (it's system-wide) and the AST > > > decision will be communicated per device by a new sysfs attribute anyway, if > > > needed? > > > > Not sure what you mean by "AST"? The IOMMU decision is pretty much > > system-wide. > > Sorry, I meant ATS, Address Translation Service, mentioned in patch 3 in this > series, and possibly be enabled for some devices for performance, as mentioned > there. Thanks for clarifying :) > So if needed, this will be another attribute, and definitely > per-device, isn't it? Yes, we may want to add a way enable ATS for external devices (perhaps global option or per-device attribute) if it turns out to cause performance issues. However, I think it can be done later if needed. I have not seen a single device actually supporting ATS (with the exception of the "hacked" one in the linked thesis of patch 3/4 ;-))