Received: by 10.192.165.148 with SMTP id m20csp4376805imm; Tue, 8 May 2018 07:32:34 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrvTwk+J0KC7BAfvOq/zxW/4z4oUfWu+MKxY3JrZRfgQznY+VMHRJzT0bwaDCgM4W6UIoK1 X-Received: by 2002:a63:6887:: with SMTP id d129-v6mr33646377pgc.128.1525789954028; Tue, 08 May 2018 07:32:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525789953; cv=none; d=google.com; s=arc-20160816; b=Lixqj7fTTK0+PMrGSs2qRLHhD1F7tDxzl7R926HczR7/FVX9biNrN2IsoiYIhxGBB+ LGgQgJlfqLoGHIGgJFPecxROYFXYQzZYuO+omC6QNNgqCZfSw6b0dY0EOxxzotWuz21W oFNWFtiMIO93QaIFkev6r/+FS+U+5RNkHXfa5XrY7iwUXrpPi1q7Q+MQcetTqh98cwOZ cLUTQ0fWpHXYw1D+4hGig25fUsycdiyz28LQhz1e79pMTMIIIpyiVPYYUlsdIO2ZnCoS o6VYfNtVlh/PqHETHwT8V25Bie1rngM3qjnoNP17SZbJGaABrW6HG4CFnG8tCMjn9/oc EJbA== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=fYtvvJkDw7MG5JsgaJlJublD+B8h00t9S1YlgW6kUAI=; b=Q+P5B+EDjTGeZ6cI6jfRgaByec2txHA3tDu+EfhVvgnPB+NLlv5zgemlpyDr5kf81T 2rplJJi21l6WTL6vfvHd92i+RIUxRLI8bsKhynpSc062zyV423m1RiEMhmbktyXy1wRQ nxreAaecDsObOSsS8ALLZwWTtNdQiviQLlaE/EviFk57Wh3rtKS29WoUsCsppZNICfyy 2lLAnB4tNKa0EAW/O7G6OkvEEfReE030WLWOyvEiZhBQKVMBH1LzeuAPqiqMHj8xS0uv o5j5JuNDmiKaUMRPHsMhGbUpjUtpJb4xJo7wMtCQmbnRIMzc0nPPE71QBBsVKQmqsFiI fxVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=gKDaitm2; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q5-v6si11990553pgc.210.2018.05.08.07.32.19; Tue, 08 May 2018 07:32:33 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=gKDaitm2; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932572AbeEHObe (ORCPT + 99 others); Tue, 8 May 2018 10:31:34 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:33498 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932549AbeEHObb (ORCPT ); Tue, 8 May 2018 10:31:31 -0400 Received: by mail-oi0-f67.google.com with SMTP id k5-v6so21699613oiw.0 for ; Tue, 08 May 2018 07:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fYtvvJkDw7MG5JsgaJlJublD+B8h00t9S1YlgW6kUAI=; b=gKDaitm2wKsyvYfVAuKQy27mx1Pvqpq0T+F4aXhrxnrrIwU7Yyztm3yjJped7+1tK+ Afq3AeA0EqBD+8VhI+a88SIlV1zWIDJYJ0dtKkpfcD4hEMUyceHkQ5CfFOu5Op5qIe2I 6cCDyUmFCCx1YiInrTaGEwheQxYnC2wGPBJmdYfU/3bGzkfxCY9PyCMeh8lODG6AOoNa KUJlbriNmNHx84sOOfhM5kqmm7gsc5IFA+oKPSG/lwiZh0L8rIJbFoc+seNERHjTzA8o VU+li2BgQcKIW+c8sKzearqwKNfiK8CZA8PFOkzPp3ugeLigrQGnWAV/tf+SjuKJMgcs 7AOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fYtvvJkDw7MG5JsgaJlJublD+B8h00t9S1YlgW6kUAI=; b=EtNfJyUN6tkA7951R6rJQ+HouKfITmJKgl4hEWeyvyQ/WXhrOcDpcbbf7Ep56xIkql qhAtsEe4e5uiNYlgKkxNuPn7yBRn7W1VOpjalg5OGjdCntJmYaDr+JKwsSTSuayVzbK/ YnPLZKdPR4gKZxBaQlTtJbaCWTBaeYIiplMRFOIaltuU50F27sV31cI0Q2Ltl1vHK69M hu6knpvOCNlz/e8EUI8w/DRrPAaNgcdhQx9sL11mBkjUthyAjE7pu2wrL8Ty+7/m4B41 UPwWWjVRiJBsp3rFUMuJFoeEYuaE0MBHTSrdiVjHj0yTPPR2WI/jbvAtl8gnEHt5Miuj HSGA== X-Gm-Message-State: ALQs6tDadfVO+Hy/ahSXuu3HEF58bIy5WMEcPdha8hydYh7Dn7B6X44k ISUbqL/UvWDXlU4/CPDSXEJ55wUQCx2LIoUGKrgrIQ== X-Received: by 2002:aca:ebd4:: with SMTP id j203-v6mr28396194oih.110.1525789890785; Tue, 08 May 2018 07:31:30 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:2d36:0:0:0:0:0 with HTTP; Tue, 8 May 2018 07:31:30 -0700 (PDT) In-Reply-To: <20180423233046.21476-5-logang@deltatee.com> References: <20180423233046.21476-1-logang@deltatee.com> <20180423233046.21476-5-logang@deltatee.com> From: Dan Williams Date: Tue, 8 May 2018 07:31:30 -0700 Message-ID: Subject: Re: [PATCH v4 04/14] PCI/P2PDMA: Clear ACS P2P flags for all devices behind switches To: Logan Gunthorpe Cc: Linux Kernel Mailing List , linux-pci@vger.kernel.org, linux-nvme@lists.infradead.org, linux-rdma , linux-nvdimm , linux-block@vger.kernel.org, Stephen Bates , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Benjamin Herrenschmidt , Alex Williamson , =?UTF-8?Q?Christian_K=C3=B6nig?= 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 Mon, Apr 23, 2018 at 4:30 PM, Logan Gunthorpe wrote: > For peer-to-peer transactions to work the downstream ports in each > switch must not have the ACS flags set. At this time there is no way > to dynamically change the flags and update the corresponding IOMMU > groups so this is done at enumeration time before the groups are > assigned. > > This effectively means that if CONFIG_PCI_P2PDMA is selected then > all devices behind any PCIe switch heirarchy will be in the same IOMMU > group. Which implies that individual devices behind any switch > heirarchy will not be able to be assigned to separate VMs because > there is no isolation between them. Additionally, any malicious PCIe > devices will be able to DMA to memory exposed by other EPs in the same > domain as TLPs will not be checked by the IOMMU. > > Given that the intended use case of P2P Memory is for users with > custom hardware designed for purpose, we do not expect distributors > to ever need to enable this option. Users that want to use P2P > must have compiled a custom kernel with this configuration option > and understand the implications regarding ACS. They will either > not require ACS or will have design the system in such a way that > devices that require isolation will be separate from those using P2P > transactions. > > Signed-off-by: Logan Gunthorpe > --- > drivers/pci/Kconfig | 9 +++++++++ > drivers/pci/p2pdma.c | 45 ++++++++++++++++++++++++++++++--------------- > drivers/pci/pci.c | 6 ++++++ > include/linux/pci-p2pdma.h | 5 +++++ > 4 files changed, 50 insertions(+), 15 deletions(-) > > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig > index b2396c22b53e..b6db41d4b708 100644 > --- a/drivers/pci/Kconfig > +++ b/drivers/pci/Kconfig > @@ -139,6 +139,15 @@ config PCI_P2PDMA > transations must be between devices behind the same root port. > (Typically behind a network of PCIe switches). > > + Enabling this option will also disable ACS on all ports behind > + any PCIe switch. This effectively puts all devices behind any > + switch heirarchy into the same IOMMU group. Which implies that > + individual devices behind any switch will not be able to be > + assigned to separate VMs because there is no isolation between > + them. Additionally, any malicious PCIe devices will be able to > + DMA to memory exposed by other EPs in the same domain as TLPs > + will not be checked by the IOMMU. > + > If unsure, say N. It seems unwieldy that this is a compile time option and not a runtime option. Can't we have a kernel command line option to opt-in to this behavior rather than require a wholly separate kernel image? Why is this text added in a follow on patch and not the patch that introduced the config option? I'm also wondering if that command line option can take a 'bus device function' address of a switch to limit the scope of where ACS is disabled.