Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1625024ybt; Sat, 11 Jul 2020 17:13:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxG/djkg4kb4MxTT6vVkcPZRjiXe1YW5XO8rfDpCFKZ6DSNis75Vq+xsD4B1ZK20dUGsq9e X-Received: by 2002:a17:906:cce6:: with SMTP id ot38mr18311515ejb.266.1594512816132; Sat, 11 Jul 2020 17:13:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594512816; cv=none; d=google.com; s=arc-20160816; b=KAHzKPFGuH69zwpWW7+VP7x9qa18piCuIJQxJQJuQB40SGYLMVU7YvPjoanGsbSy8O vOMhRBsHRP8irEmJTtHU3Y/pHxEaI0RyNwkvUzVV+U/3UojeWYWafOrmEWNQyMMvV/T3 +S+r8FJWDXcXXAq1IlkquHUD/rOeqY+3JcJUeQHZj405dtskqmi9PAf2zycwJxA5fF8i 8PWmkDuFfj6QpxlRRdBvZsS7gy5X62IEZgNeazfgIKPV7B3AFOSAhmpk6P7qsFFGaDH4 Ea5NTuLf4FBAmFz57Ewys+a5YN4z/TZUx8rqGdS14dEAIzY++iTBJejb8guyjnF1gBRG KY1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :reply-to:in-reply-to:references:mime-version:dkim-signature; bh=pou8Xfe98lnWE/rbRKHVE6SyHdTXSqWjqH3LyMm2g1g=; b=kzyonvP4SeEKC7PUzruoqTD3AmlnO61ytM34jgc0ydHiqq67chU3FjPYmWHBtewGGs +B+BIW4Pc6pMqJnvLBIPKXRn3fv4FVAurgJLe6RTM/KdLGsMJW9oeY8swtWNQm4P4Gfj bh9xNjNqAol/AF+tjSR5Q3zuKNcFC8o4Qd3Lzs4OFcnaNwUZuPK2uCC4wEMd7116wFv8 ULZN1kcepKGkxf+Z6zJFrJX9o5hSqqNLKXr5einl0bLOcBf+QGyXIl17yHHryuDilgnW /ziH6nSe56XJx2iY7ZG8MCwtNWS5+SKFrhqlQDndSR4aCIA9+qb/9/LZc99p1T0XYMzS +kxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VS6vv99V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h16si6543005edz.526.2020.07.11.17.12.59; Sat, 11 Jul 2020 17:13:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=VS6vv99V; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727785AbgGLAJE (ORCPT + 99 others); Sat, 11 Jul 2020 20:09:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726939AbgGLAJE (ORCPT ); Sat, 11 Jul 2020 20:09:04 -0400 Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C60ACC08C5DD; Sat, 11 Jul 2020 17:09:03 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id e12so7376117qtr.9; Sat, 11 Jul 2020 17:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=pou8Xfe98lnWE/rbRKHVE6SyHdTXSqWjqH3LyMm2g1g=; b=VS6vv99Vg+bqf95zuX4c+7cQB4qH9c0v2nf/YVV/5Qq7W4TIfgoKhTyLLt6gllzaD2 2sDIc+gSeKdyaeH2/4iMGWnT8plbBkjDfLgFjWYViZMWB9YKL4GtSkZz70yQFAZAG8F2 opo6cytCGbpzgnKdVEI2SGN+iIsXI4eU6XpBF1rWFlKxUtShEQYcsVEub/ttLfOP2cvw bklV724Jb7ZwSBei3wih3mzvvEvZ+YHxRc/+syR53QZY7B1+mMf8qr6TWML9wNpHoX2Y DFgWis5Phn93qJ3N9gOPk1mbtexwwRcKzyev5tpM9UO+t4bWtWEJ3h2vcNNjX8HbzcDU oLgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=pou8Xfe98lnWE/rbRKHVE6SyHdTXSqWjqH3LyMm2g1g=; b=RxFq4MDKn5EPmRWwDXyKf3tdWoVn+Usj4W3AJBnuOafkgPP20eA4M001LJyGFbxBtA /Q2M21i0Y42ocC+xHfhnaDlTbRYSefksmH/ohPR3hgTZZcDTu0qDHRq8MuIJ1qdFbI05 A5FRAoEJH4RQglYYyIH9yUsMkeCkFr13op+RkiFI1DN/RxLZP6VLIqRgpQTfOaTJo69n +onCZ74frtEo6qg9CrrxMY7p8FKiyHdGh7zs+8UKih1H2YGcq5QcKquh+o3bCtwM3/am zmj76KjaLxmqZBnpdMqXOUkL1dfmkKNIgZsTJoHcbqZ3Lm4n/gRccnofAz2zZHklHNML 2n9Q== X-Gm-Message-State: AOAM531RjuJNpgjrQL8bu9Qy1fEldOiUxCAYgm2fR+3QmldHK+WVLtB/ 8F2TLeQTy8u0rEhlKqnjgqeQsd1oGqcKZehKBPI= X-Received: by 2002:ac8:518b:: with SMTP id c11mr76434264qtn.195.1594512542683; Sat, 11 Jul 2020 17:09:02 -0700 (PDT) MIME-Version: 1.0 References: <20200711195346.GA132330@bjorn-Precision-5520> In-Reply-To: <20200711195346.GA132330@bjorn-Precision-5520> Reply-To: rajatxjain@gmail.com From: Rajat Jain Date: Sat, 11 Jul 2020 17:08:51 -0700 Message-ID: Subject: Re: [PATCH v4 4/4] PCI/ACS: Enable PCI_ACS_TB for untrusted/external-facing devices To: Bjorn Helgaas Cc: Rajat Jain , "Raj, Ashok" , David Woodhouse , Lu Baolu , Joerg Roedel , Bjorn Helgaas , "Rafael J. Wysocki" , Len Brown , "open list:AMD IOMMU (AMD-VI)" , Linux Kernel Mailing List , linux-pci , ACPI Devel Maling List , "Krishnakumar, Lalithambika" , Mika Westerberg , Jean-Philippe Brucker , Prashant Malani , Benson Leung , Todd Broch , Alex Levin , Mattias Nissler , Bernie Keany , Aaron Durbin , Diego Rivas , Duncan Laurie , Furquan Shaikh , Jesse Barnes , Christian Kellner , Alex Williamson , Greg Kroah-Hartman , "Oliver O'Halloran" , Saravana Kannan , Suzuki K Poulose , Arnd Bergmann , Heikki Krogerus Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 11, 2020 at 12:53 PM Bjorn Helgaas wrote: > > On Fri, Jul 10, 2020 at 03:53:59PM -0700, Rajat Jain wrote: > > On Fri, Jul 10, 2020 at 2:29 PM Raj, Ashok wrote: > > > On Fri, Jul 10, 2020 at 03:29:22PM -0500, Bjorn Helgaas wrote: > > > > On Tue, Jul 07, 2020 at 03:46:04PM -0700, Rajat Jain wrote: > > > > > When enabling ACS, enable translation blocking for external facing ports > > > > > and untrusted devices. > > > > > > > > > > Signed-off-by: Rajat Jain > > > > > --- > > > > > v4: Add braces to avoid warning from kernel robot > > > > > print warning for only external-facing devices. > > > > > v3: print warning if ACS_TB not supported on external-facing/untrusted ports. > > > > > Minor code comments fixes. > > > > > v2: Commit log change > > > > > > > > > > drivers/pci/pci.c | 8 ++++++++ > > > > > drivers/pci/quirks.c | 15 +++++++++++++++ > > > > > 2 files changed, 23 insertions(+) > > > > > > > > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > > > > > index 73a8627822140..a5a6bea7af7ce 100644 > > > > > --- a/drivers/pci/pci.c > > > > > +++ b/drivers/pci/pci.c > > > > > @@ -876,6 +876,14 @@ static void pci_std_enable_acs(struct pci_dev *dev) > > > > > /* Upstream Forwarding */ > > > > > ctrl |= (cap & PCI_ACS_UF); > > > > > > > > > > + /* Enable Translation Blocking for external devices */ > > > > > + if (dev->external_facing || dev->untrusted) { > > > > > + if (cap & PCI_ACS_TB) > > > > > + ctrl |= PCI_ACS_TB; > > > > > + else if (dev->external_facing) > > > > > + pci_warn(dev, "ACS: No Translation Blocking on external-facing dev\n"); > > > > > + } > > > > > > > > IIUC, this means that external devices can *never* use ATS and > > > > can never cache translations. > > > > Yes, but it already exists today (and this patch doesn't change that): > > 521376741b2c2 "PCI/ATS: Only enable ATS for trusted devices" > > > > IMHO any external device trying to send ATS traffic despite having ATS > > disabled should count as a bad intent. And this patch is trying to > > plug that loophole, by blocking the AT traffic from devices that we do > > not expect to see AT from anyway. > > Thinking about this some more, I wonder if Linux should: > > - Explicitly disable ATS for every device at enumeration-time, e.g., > in pci_init_capabilities(), > > - Enable PCI_ACS_TB for every device (not just external-facing or > untrusted ones), > > - Disable PCI_ACS_TB for the relevant devices along the path only > when enabling ATS. > > One nice thing about doing that is that the "untrusted" test would be > only in pci_enable_ats(), and we wouldn't need one in > pci_std_enable_acs(). Yes, this could work. I think I had thought about this but I'm blanking out on why I had given it up. I think it was because of the possibility that some bridges may have "Translation blocking" disabled, even if not all their descendents were trusted enough to enable ATS on them. But now thinking about this again, as long as we retain the policy of not enabling ATS on external devices (and thus enable TB for sure on them), this should not be a problem. WDYT? > > It's possible BIOS gives us devices with ATS enabled, and this might > break them, but that seems like something we'd want to find out about. > Why would they break? We'd disable ATS on each device as we enumerate them, so they'd be functional, just with ATS disabled until it is enabled again on internal devices as needed. Which would be WAI behavior? Thanks, , Rajat > Bjorn