Received: by 10.192.165.148 with SMTP id m20csp4747742imm; Tue, 8 May 2018 13:44:28 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoLkn+ErpNqa0U4el8kpi0Oah4WcCDUkqMIy2Sb/gx/9YJEQ2F/auq6nk6jQ+Ghrpkj4quQ X-Received: by 10.98.0.194 with SMTP id 185mr41456702pfa.238.1525812268882; Tue, 08 May 2018 13:44:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525812268; cv=none; d=google.com; s=arc-20160816; b=XzxeQGsnowHu28ngITsSpVpTLoQt+axo4FFTLOeWxn6h+ULDw1ghy3bUa/taX5suFd YqPnSELl1clWQkDte0O4II1m/C9NtlNRCh7GlDAaFB4kRfIthPciLGpTLbG9P+MLtbEL 2THUXjzYYkPvAs6D2QlRs97G99n+ZCpeeS/AFn5k+bHRYIleREb3A33uwkV+us23yYjh 826hwN2WII3DiSX1uMTm/KANIWdnSxytERyGahyywSLsQBUPtukMk8xXbjXDNapQ9Q4/ 3otRHxUYUU31nFpQbHblTnaXZ5PFxdmXNN8olvqaCDPzRoqzz3E3Tov9ORkUXu7pa8go oxTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=xmS0hKvsUhhUpJlowBaVK7hUKdlqwLuMfuvd64reqOI=; b=Xfhg6Vj3UenFIhPWYCtXVn1b9ObIqq5N0qIoQjEb5M9WkTjrA8ejHi9pi3N1FW9WWR AFWQcoAtzW08NbhIKc8F3QrUQQI8zSR5F/C6mV/l4rw5XQD+5TBJS22TVj8OZzTI+KgZ quMIXZigKAO3nuiEMihWqBfVe54a/SNScSVBbX/OKMfn5W+KKkkfLvLQ2PTAztDRJpcD YRsTDvsltvE84h0RtWAqxeGirndAX2YFHbda4s8y/Nz4ZL+tbO49Hw4ELtWZ0+oMdEA9 ZYk0P80NhEbgPP6Ky7RoPgf0k/goY7P/syXWkGs57kKsYHRI7/jXYe7/mlg/P/eHgtho od6w== 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 32-v6si13714007plc.252.2018.05.08.13.44.14; Tue, 08 May 2018 13:44:28 -0700 (PDT) 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755882AbeEHUnp (ORCPT + 99 others); Tue, 8 May 2018 16:43:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52821 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755647AbeEHUnn (ORCPT ); Tue, 8 May 2018 16:43:43 -0400 Received: from smtp.corp.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0987C4E918; Tue, 8 May 2018 20:43:43 +0000 (UTC) Received: from w520.home (ovpn-116-103.phx2.redhat.com [10.3.116.103]) by smtp.corp.redhat.com (Postfix) with ESMTP id B21EF30001D9; Tue, 8 May 2018 20:43:41 +0000 (UTC) Date: Tue, 8 May 2018 14:43:41 -0600 From: Alex Williamson To: Logan Gunthorpe Cc: Christian =?UTF-8?B?S8O2bmln?= , Bjorn Helgaas , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org, linux-nvdimm@lists.01.org, linux-block@vger.kernel.org, Stephen Bates , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , Dan Williams , =?UTF-8?B?SsOpcsO0bWU=?= Glisse , Benjamin Herrenschmidt Subject: Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches Message-ID: <20180508144341.0441b676@w520.home> In-Reply-To: References: <20180423233046.21476-1-logang@deltatee.com> <20180423233046.21476-5-logang@deltatee.com> <20180507231306.GG161390@bhelgaas-glaptop.roam.corp.google.com> <0b4183ef-e720-204b-9e85-b9eaf7a4136a@deltatee.com> <3584a6ac-95c7-5d23-1859-aee30605776e@deltatee.com> <20180508133407.57a46902@w520.home> <5fc9b1c1-9208-06cc-0ec5-1f54c2520494@deltatee.com> <20180508141331.7cd737cb@w520.home> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 08 May 2018 20:43:43 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 May 2018 14:19:05 -0600 Logan Gunthorpe wrote: > On 08/05/18 02:13 PM, Alex Williamson wrote: > > Well, I'm a bit confused, this patch series is specifically disabling > > ACS on switches, but per the spec downstream switch ports implementing > > ACS MUST implement direct translated P2P. So it seems the only > > potential gap here is the endpoint, which must support ATS or else > > there's nothing for direct translated P2P to do. The switch port plays > > no part in the actual translation of the request, ATS on the endpoint > > has already cached the translation and is now attempting to use it. > > For the switch port, this only becomes a routing decision, the request > > is already translated, therefore ACS RR and EC can be ignored to > > perform "normal" (direct) routing, as if ACS were not present. It would > > be a shame to go to all the trouble of creating this no-ACS mode to find > > out the target hardware supports ATS and should have simply used it, or > > we should have disabled the IOMMU altogether, which leaves ACS disabled. > > Ah, ok, I didn't think it was the endpoint that had to implement ATS. > But in that case, for our application, we need NVMe cards and RDMA NICs > to all have ATS support and I expect that is just as unlikely. At least > none of the endpoints on my system support it. Maybe only certain GPUs > have this support. Yes, GPUs seem to be leading the pack in implementing ATS. So now the dumb question, why not simply turn off the IOMMU and thus ACS? The argument of using the IOMMU for security is rather diminished if we're specifically enabling devices to poke one another directly and clearly this isn't favorable for device assignment either. Are there target systems where this is not a simple kernel commandline option? Thanks, Alex