Received: by 10.213.65.68 with SMTP id h4csp523598imn; Tue, 13 Mar 2018 11:46:28 -0700 (PDT) X-Google-Smtp-Source: AG47ELusgp0uZ5Rx1/I/bxBXPJ3I0J7NM6Goehy78e4WbzLSW8CtATEMawhZtvhF+Gz+U/q4Rm8t X-Received: by 10.99.123.71 with SMTP id k7mr1356881pgn.134.1520966788222; Tue, 13 Mar 2018 11:46:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520966788; cv=none; d=google.com; s=arc-20160816; b=M/YfIlQ/8RG8eCIk2JRct7kuieW8wDidBSm5FqDHskQfXu4UIu2Gc24rjh0l1oQxq6 KjqBCWVpuqxMuE9VWkvPYQa2n2q0+Kyiat7wwuFxvMzt2ZBDH78xlKgcUoQ4/CVMTGKK S9qIJ3hPy7EdIaC2oTGtJEVED8BXS0MErS73yrRu6XmaKVtDCCy1r5qutr7gimT4G47p 171J1OsnQkzqE7Ib7H7rm2BFzNfxKI4idcnK45WjqcOUuCjjh7LQmV6IuJIwgJyH8mcT r2lCqmTgMKsVyyKzX0yZHshS/SjizNoUPZAumDoAMwtLJ4jk+V8atGPbNmeDRIoURIIY eGdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:arc-authentication-results; bh=F6S0WH4GeDgHkH1X4WdVaBhD2e1i5yqG/TIhTg8kjT4=; b=YEBUwM1AnlUGT33M7Cg9rjOH0Dyqzb25JSfZKdOi9Xgoxuhb8YwcvRFmipJpsHS9du MIuxQhaPqB7labsnFGQ8qYpXg9ZsdpokZnFF++8xybZM0Y4bmO5rfJ9YvFbPN3BGWOHF KCpegdAELAVhg0P3iFGgxe8ByVbAo1txa6M/+5FestJRD6Hui1rOXhGolRebw9diCYL0 tBTfxEQBy1Kph8/TSh+a6W3RqeB9orrkBJrxmDE+2LCqWZjrmSLvZIyRNoxowQdRzrOA kwuIzlhGn5A0fujCP7bCqwxviW4h1p/643Zpdd4mkOlKrB0/3+ZwYp0OUHwOY1nnyx4I dXqg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a10-v6si515975plm.745.2018.03.13.11.46.11; Tue, 13 Mar 2018 11:46: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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752351AbeCMSpL (ORCPT + 99 others); Tue, 13 Mar 2018 14:45:11 -0400 Received: from ale.deltatee.com ([207.54.116.67]:34390 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751529AbeCMSpJ (ORCPT ); Tue, 13 Mar 2018 14:45:09 -0400 Received: from guinness.priv.deltatee.com ([172.16.1.162]) by ale.deltatee.com with esmtp (Exim 4.89) (envelope-from ) id 1evouZ-0005Oa-08; Tue, 13 Mar 2018 12:44:35 -0600 To: Sinan Kaya , 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 Cc: Stephen Bates , Christoph Hellwig , Jens Axboe , Keith Busch , Sagi Grimberg , Bjorn Helgaas , Jason Gunthorpe , Max Gurtovoy , Dan Williams , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Benjamin Herrenschmidt , Alex Williamson References: <20180312193525.2855-1-logang@deltatee.com> <20180312193525.2855-2-logang@deltatee.com> <59fd2f5d-177f-334a-a9c4-0f8a6ec7c303@codeaurora.org> <24d8e5c2-065d-8bde-3f5d-7f158be9c578@deltatee.com> <52cbbbc4-c488-f83f-8d02-14d455b4efd7@codeaurora.org> From: Logan Gunthorpe Message-ID: <3e738f95-d73c-4182-2fa1-8664aafb1ab7@deltatee.com> Date: Tue, 13 Mar 2018 12:44:34 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <52cbbbc4-c488-f83f-8d02-14d455b4efd7@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 172.16.1.162 X-SA-Exim-Rcpt-To: alex.williamson@redhat.com, benh@kernel.crashing.org, jglisse@redhat.com, dan.j.williams@intel.com, maxg@mellanox.com, jgg@mellanox.com, bhelgaas@google.com, sagi@grimberg.me, keith.busch@intel.com, axboe@kernel.dk, hch@lst.de, sbates@raithlin.com, linux-block@vger.kernel.org, linux-nvdimm@lists.01.org, linux-rdma@vger.kernel.org, linux-nvme@lists.infradead.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, okaya@codeaurora.org X-SA-Exim-Mail-From: logang@deltatee.com X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on ale.deltatee.com X-Spam-Level: X-Spam-Status: No, score=-8.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, GREYLIST_ISWHITE,T_RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 Subject: Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13/03/18 11:49 AM, Sinan Kaya wrote: >> And there's also the ACS problem which means if you want to use P2P on the root ports you'll have to disable ACS on the entire system. (Or preferably, the IOMMU groups need to get more sophisticated to allow for dynamic changes). >> > > Do you think you can keep a pointer to the parent bridge instead of querying it > via get_upstream_bridge_port() here so that we can reuse your > pci_p2pdma_disable_acs() in the future. Keep a pointer where? pci_p2pdma_disable_acs() and pci_p2pdma_add_client() are used in completely different cases on completely different devices. There really is no overlap and no obvious place to store the port pointer (except in the struct pci_dev itself, in which case why not just call the function again). > +int pci_p2pdma_disable_acs(struct pci_dev *pdev) > +{ > + struct pci_dev *up; > + int pos; > + u16 ctrl; > + > + up = get_upstream_bridge_port(pdev); > + if (!up) > + return 0; > > Some future device would only deal with pci_p2pdma_add_client(() for whitelisting > instead of changing all of your code. That's a problem for whoever writes the future code. > We should at least limit the usage of get_upstream_bridge_port() family of functions > to probe time only. Why? > We can tell iommu to do one to one translation by passing iommu.passthrough=1 to kernel > command line to have identical behavior to your switch case. Well, someone will need to write code for all available IOMMUs to support this. That's a very big project. Logan