From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1F906D1D896 for ; Tue, 15 Oct 2024 18:25:56 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9F58610E5D9; Tue, 15 Oct 2024 18:25:55 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=deltatee.com header.i=@deltatee.com header.b="Uor/DIgo"; dkim-atps=neutral X-Greylist: delayed 2440 seconds by postgrey-1.36 at gabe; Tue, 15 Oct 2024 18:25:54 UTC Received: from ale.deltatee.com (ale.deltatee.com [204.191.154.188]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1AA1810E5D6; Tue, 15 Oct 2024 18:25:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=deltatee.com; s=20200525; h=Subject:In-Reply-To:From:References:Cc:To: MIME-Version:Date:Message-ID:content-disposition; bh=BPeAYwyDZnaS1vv2XNPfZK8JukXiODb9mxxHVbQ3E+A=; b=Uor/DIgoky+qPE7WjyzQs2QUoh pa9jfeEf4hSn43vumap+WTU9ySIFIptUHHIxWmAlLdlpStg+fDuQH+fHD59TAKWfwIRMiaaDR0UEy SZi/IbQOCtG3ci3qvidmZ21tkTKkai5YP2+VflPwJXD1bzQb/XGCvlMEAFWx1RNpUTZ9yKXsOIIET 5bTy5D7MvjTFakF++0jLxfFVZykpsVg76Pp33TQrPwRYplNcBsdno4AGEBnJvUHmAuBaVXIm99Av9 JDIn/wXmWkSdmwUfmxI5TFK/LgK7rf1cmWN7+LQbaNff3J0jw4l2PXmNv7VkErw4Z5/6gNIZlAf/R RHYhzW5g==; Received: from d104-157-31-28.abhsia.telus.net ([104.157.31.28] helo=[192.168.1.250]) by ale.deltatee.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1t0lbb-00A8Kk-2E; Tue, 15 Oct 2024 11:45:13 -0600 Message-ID: Date: Tue, 15 Oct 2024 11:45:09 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Vivek Kasireddy , dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org Cc: Bjorn Helgaas , linux-pci@vger.kernel.org References: <20241012024524.1377836-1-vivek.kasireddy@intel.com> <20241012024524.1377836-2-vivek.kasireddy@intel.com> Content-Language: en-CA From: Logan Gunthorpe In-Reply-To: <20241012024524.1377836-2-vivek.kasireddy@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 104.157.31.28 X-SA-Exim-Rcpt-To: vivek.kasireddy@intel.com, dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, bhelgaas@google.com, linux-pci@vger.kernel.org X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: [PATCH v1 1/5] PCI/P2PDMA: Don't enforce ACS check for functions of same device X-SA-Exim-Version: 4.2.1 (built Wed, 06 Jul 2022 17:57:39 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On 2024-10-11 20:40, Vivek Kasireddy wrote: > Functions of the same PCI device (such as a PF and a VF) share the > same bus and have a common root port and typically, the PF provisions > resources for the VF. Therefore, they can be considered compatible > as far as P2P access is considered. > > Currently, although the distance (2) is correctly calculated for > functions of the same device, an ACS check failure prevents P2P DMA > access between them. Therefore, introduce a small function named > same_pci_device_functions() to determine if the provider and > client belong to the same device and facilitate P2P DMA between > them by not enforcing the ACS check. I'm not totally opposed to this. But the current code was done this way for a reason: we can't be sure that functions on any given device can talk to each other. So this change may break if used with other devices with multiple functions that can't talk to each other. That being said, the only alternative I can think of is another list of allowed devices. However, given the pain it's been maintaining allowed root ports, I'm not very enthusiastic about creating another list of allowed devices in the kernel. Logan