Received: by 10.213.65.68 with SMTP id h4csp495508imn; Tue, 13 Mar 2018 10:51:19 -0700 (PDT) X-Google-Smtp-Source: AG47ELv79/iUzFSWd2FeHqrJBoHpjl9WNco1xZBChd2+0Mz+QQx3csNp2WQSO4ezlqKfLv17IL18 X-Received: by 10.99.131.73 with SMTP id h70mr1147131pge.195.1520963479918; Tue, 13 Mar 2018 10:51:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520963479; cv=none; d=google.com; s=arc-20160816; b=oh3wQlPhY/wzbktq12GbZ8zRF32wqHVGgZGygl+bq+V4lrG5aE6LYygK4Xuk+kB1Kc W11OFqiC5zTGYBGMWKToE55DZKTzqLGLIIJO2HmZ1edzMVncmNt4k5k6rln80n5lVx6n i6OqySjBaY1G00cbpKayYfSAuNg+lPlxGVCLAfrnJNRlC3ih9hPViHNhkjjTRdx2P+73 8TB68HLHhht0IcpVnK4CO0Pkv8H3TaXidcPxEM06+fJMyfCJUQBEITtFWwJ6JqgUGCxA min4fwOmcy6Q9lZEBJWHk4lsQKZlf0Wvfljq50VcwmxgJEwfahj38rhsQ5xxuWwNR+jE cOGg== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=o9i71skwDgusQIh0Ta6deq/nVjoxMXj8s0dC5xTOZq0=; b=hpHbY96EOyM5dyYAFeBNaccYV1Ash1O2559O5NdvyTigfLm5lWK3yjg0rxfUXeeFD4 4q5JcPuKw23tQbbSg3JBj502YEc8/ILz0iDF84GwaSbiV4YLM6USI2i8eV3iKu9rcQX+ 3ndFti9kiWJWdDowuYMA6Zf/bedlfqfhgSaph5sx0tMGILn2gy8rdYBZaVBsgfhvoE/F sOVZC3ykcXzDrBcY2ZLxSiipHfdZnhJ8alXNZ6yg58xpQUHdHzdM4OGICnI3EMvPVSLu v7KkXR+A5U+Fe6MPc/lEQbafDVEovTMIvAGQxqb4uNc2oHLwiQjSpAA7QrifLAGHP5JO nhAQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=Q4UWCrrp; dkim=pass header.i=@codeaurora.org header.s=default header.b=hSyhHp9i; 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 bj1-v6si440803plb.711.2018.03.13.10.51.05; Tue, 13 Mar 2018 10:51:19 -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=@codeaurora.org header.s=default header.b=Q4UWCrrp; dkim=pass header.i=@codeaurora.org header.s=default header.b=hSyhHp9i; 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 S1752261AbeCMRts (ORCPT + 99 others); Tue, 13 Mar 2018 13:49:48 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:55970 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751534AbeCMRtq (ORCPT ); Tue, 13 Mar 2018 13:49:46 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 8E0D26084A; Tue, 13 Mar 2018 17:49:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520963385; bh=tUWHSXWOHrP7OnQAwWBIWQ7JXhIxOiyplM93Ls01EiM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Q4UWCrrpqLA0Xct9464oCgKScBBVFJ4Z7OSvvBHV5EnjgqXWsmlK5Lv8vhyoZETm/ Xnc5RJ1bqDPRilU1cDZXGb0vQoG2WN1rQ4BEG0OhB4rucOb2H/QQOZHpOJJJKXmMiB cQCy+kfVWbJV+cKTBv4nEVT3+irtwaCT1VEdsMSk= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.235.228.150] (global_nat1_iad_fw.qualcomm.com [129.46.232.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: okaya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id BDDBF60590; Tue, 13 Mar 2018 17:49:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520963384; bh=tUWHSXWOHrP7OnQAwWBIWQ7JXhIxOiyplM93Ls01EiM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hSyhHp9ihlgp/LlvvcAtSWez+2edH6okAkVGYujVufsQ0qqCc8ntWHkGgmDqIh9ua oTtWkQXNHqArIidzDJWOIzXEyiqmgmPljUnJ0Tn/HQhy/DYRZYgNh34IHUFXT/iS1W TJM9oIuFQYN0+ufYM65gt1ozW78SoR+2Rr1JUzmM= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org BDDBF60590 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=okaya@codeaurora.org Subject: Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory To: Logan Gunthorpe , 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> From: Sinan Kaya Message-ID: <52cbbbc4-c488-f83f-8d02-14d455b4efd7@codeaurora.org> Date: Tue, 13 Mar 2018 13:49:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <24d8e5c2-065d-8bde-3f5d-7f158be9c578@deltatee.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/13/2018 12:43 PM, Logan Gunthorpe wrote: > > > On 12/03/18 09:28 PM, Sinan Kaya wrote: >> On 3/12/2018 3:35 PM, Logan Gunthorpe wrote: >> Regarding the switch business, It is amazing how much trouble you went into >> limit this functionality into very specific hardware. >> >> I thought that we reached to an agreement that code would not impose >> any limits on what user wants. >> >> What happened to all the emails we exchanged? > > It turns out that root ports that support P2P are far less common than anyone thought. So it will likely have to be a white list. Nobody else seems keen on allowing the user to enable this on hardware that doesn't work. The easiest solution is still limiting it to using a switch. From there, if someone wants to start creating a white-list then that's probably the way forward to support root ports. I thought only few root ports had problem. Thanks for clarifying that. > > 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. +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. We should at least limit the usage of get_upstream_bridge_port() family of functions to probe time only. > Additionally, once you allow for root ports you may find the IOMMU getting in the way. 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. > > So there are great deal more issues to sort out if you don't restrict to devices behind switches. > > Logan > -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.