From nobody Mon Feb 9 12:25:21 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 191DD27CCE0; Sun, 2 Nov 2025 08:01:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762070501; cv=none; b=r2Vmm/b4LG9dGAhCjbUpcA1UHiVAmHenHRo69Wf+RoQq5MRLdrleiJt3/cJWbcgkABwyV8dLHV+LH0/qhejkxIAdkX2yIKKLObTyp90Y/O67nV2CERsxw+tKrQw/MYXqmW0Gt9HSLAPsvhIhxHCpoJt0j/tUggwCqy8K+rWMH4I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762070501; c=relaxed/simple; bh=YEj7lVMjG/2/HYFIZSu2/o74kulmj1G6rnGXJYyVmnc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=o0JXB8QCrFKk3H7rUGMRbivikq/kuyEMGHY6AetNMKhtFtb5ipABDxwxPrJ2+YerSmsHq8mcISwaIi+BzFXzzUF61W6foGOHfmtFGLHMJqipX5VWRblxhI8C8vRDZpQs/vUvw2E2qsQ7x3X8+1n/r9+ODAj97JnjA8+3Q0snBMk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GeQrdtgq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GeQrdtgq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 50DD8C116B1; Sun, 2 Nov 2025 08:01:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762070501; bh=YEj7lVMjG/2/HYFIZSu2/o74kulmj1G6rnGXJYyVmnc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GeQrdtgqOBrp3SSL7bb5BM8UNhWStBmhQNvnJTJpY6b87guzPaUbYr977bcX7Pcys Yxc87/WEOCpr6+I0a7aOihy/M040Q6oJAKt57MOitktMdBkKYSmRvVAAGUFmu4cRLb GiF0K3SKuEWa1PiQpGez3mj2ynIUSgJZxBoWSI1HJOfm04/lnNUCVZWvEW4UjqNf4s jjzG8Y+HrfUFjn/1FmYPnjRoCfkF/8U5zQ5n8a4lLbMq7qhZ1JrKOuODyBz90mBK/0 RitZslKa0LprpIxm9rOwwbV/sDXoBPlF9joy4PQkCxYROfGTF3sOOrE20g3w3riJVo h/0R1XRSwONlw== From: Leon Romanovsky To: Bjorn Helgaas , Logan Gunthorpe , Jens Axboe , Robin Murphy , Joerg Roedel , Will Deacon , Marek Szyprowski , Jason Gunthorpe , Leon Romanovsky , Andrew Morton , Jonathan Corbet , Sumit Semwal , =?utf-8?q?Christian_K=C3=B6nig?= , Alex Williamson , Kees Cook , "Gustavo A. R. Silva" , Ankit Agrawal , Yishai Hadas , Shameer Kolothum , Kevin Tian Cc: Krishnakant Jaju , Matt Ochs , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, iommu@lists.linux.dev, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, kvm@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH v6 05/11] PCI/P2PDMA: Document DMABUF model Date: Sun, 2 Nov 2025 10:00:53 +0200 Message-ID: <20251102-dmabuf-vfio-v6-5-d773cff0db9f@nvidia.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251102-dmabuf-vfio-v6-0-d773cff0db9f@nvidia.com> References: <20251102-dmabuf-vfio-v6-0-d773cff0db9f@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: b4 0.15-dev Content-Transfer-Encoding: quoted-printable From: Jason Gunthorpe Reflect latest changes in p2p implementation to support DMABUF lifecycle. Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe --- Documentation/driver-api/pci/p2pdma.rst | 95 +++++++++++++++++++++++++----= ---- 1 file changed, 72 insertions(+), 23 deletions(-) diff --git a/Documentation/driver-api/pci/p2pdma.rst b/Documentation/driver= -api/pci/p2pdma.rst index d0b241628cf1..c43ec1356471 100644 --- a/Documentation/driver-api/pci/p2pdma.rst +++ b/Documentation/driver-api/pci/p2pdma.rst @@ -9,22 +9,47 @@ between two devices on the bus. This type of transaction = is henceforth called Peer-to-Peer (or P2P). However, there are a number of issues that make P2P transactions tricky to do in a perfectly safe way. =20 -One of the biggest issues is that PCI doesn't require forwarding -transactions between hierarchy domains, and in PCIe, each Root Port -defines a separate hierarchy domain. To make things worse, there is no -simple way to determine if a given Root Complex supports this or not. -(See PCIe r4.0, sec 1.3.1). Therefore, as of this writing, the kernel -only supports doing P2P when the endpoints involved are all behind the -same PCI bridge, as such devices are all in the same PCI hierarchy -domain, and the spec guarantees that all transactions within the -hierarchy will be routable, but it does not require routing -between hierarchies. - -The second issue is that to make use of existing interfaces in Linux, -memory that is used for P2P transactions needs to be backed by struct -pages. However, PCI BARs are not typically cache coherent so there are -a few corner case gotchas with these pages so developers need to -be careful about what they do with them. +For PCIe the routing of TLPs is well defined up until they reach a host br= idge +or root port. If the path includes PCIe switches then based on the ACS set= tings +the transaction can route entirely within the PCIe hierarchy and never rea= ch the +root port. The kernel will evaluate the PCIe topology and always permit P2P +in these well defined cases. + +However, if the P2P transaction reaches the host bridge then it might have= to +hairpin back out the same root port, be routed inside the CPU SOC to anoth= er +PCIe root port, or routed internally to the SOC. + +As this is not well defined or well supported in real HW the kernel defaul= ts to +blocking such routing. There is an allow list to allow detecting known-goo= d HW, +in which case P2P between any two PCIe devices will be permitted. + +Since P2P inherently is doing transactions between two devices it requires= two +drivers to be co-operating inside the kernel. The providing driver has to = convay +its MMIO to the consuming driver. To meet the driver model lifecycle rules= the +MMIO must have all DMA mapping removed, all CPU accesses prevented, all pa= ge +table mappings undone before the providing driver completes remove(). + +This requires the providing and consuming driver to actively work together= to +guarentee that the consuming driver has stopped using the MMIO during a re= moval +cycle. This is done by either a synchronous invalidation shutdown or waiti= ng +for all usage refcounts to reach zero. + +At the lowest level the P2P subsystem offers a naked struct p2p_provider t= hat +delegates lifecycle management to the providing driver. It is expected that +drivers using this option will wrap their MMIO memory in DMABUF and use DM= ABUF +to provide an invalidation shutdown. These MMIO pages have no struct page,= and +if are used with mmap() must create special PTEs. As such there are very f= ew +kernel uAPIs that can accept pointers to them, in particular they cannot b= e used +with read()/write(), including O_DIRECT. + +Building on this, the subsystem offers a layer to wrap the MMIO in a ZONE_= DEVICE +pggmap of MEMORY_DEVICE_PCI_P2PDMA to create struct pages. The lifecylce of +pgmap ensures that when the pgmap is destroyed all other drivers have stop= ped +using the MMIO. This option works with O_DIRECT flows, in some cases, if t= he +underlying subsystem supports handling MEMORY_DEVICE_PCI_P2PDMA through +FOLL_PCI_P2PDMA. The use of FOLL_LONGTERM is prevented. As this relies on = pgmap +it also relies on architecture support along with alignment and minimum si= ze +limitations. =20 =20 Driver Writer's Guide @@ -114,14 +139,38 @@ allocating scatter-gather lists with P2P memory. Struct Page Caveats ------------------- =20 -Driver writers should be very careful about not passing these special -struct pages to code that isn't prepared for it. At this time, the kernel -interfaces do not have any checks for ensuring this. This obviously -precludes passing these pages to userspace. +While the MEMORY_DEVICE_PCI_P2PDMA pages can be installed in VMAs, +pin_user_pages() and related will not return them unless FOLL_PCI_P2PDMA i= s set. =20 -P2P memory is also technically IO memory but should never have any side -effects behind it. Thus, the order of loads and stores should not be impor= tant -and ioreadX(), iowriteX() and friends should not be necessary. +The MEMORY_DEVICE_PCI_P2PDMA pages require care to support in the kernel. = The +KVA is still MMIO and must still be accessed through the normal +readX()/writeX()/etc helpers. Direct CPU access (e.g. memcpy) is forbidden= , just +like any other MMIO mapping. While this will actually work on some +architectures, others will experiance corruption or just crash in the kern= el. +Supporting FOLL_PCI_P2PDMA in a subsystem requires scrubbing it to ensure = no CPU +access happens. + + +Usage With DMABUF +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +DMABUF provides an alternative to the above struct page based +client/provider/orchestrator system. In this mode the exporting driver wil= l wrap +some of its MMIO in a DMABUF and give the DMABUF FD to userspace. + +Userspace can then pass the FD to an importing driver which will ask the +exporting driver to map it. + +In this case the initator and target pci_devices are known and the P2P sub= system +is used to determine the mapping type. The phys_addr_t based DMA API is us= ed to +establish the dma_addr_t. + +Lifecycle is controlled by DMABUF move_notify(), when the exporting driver= wants +to remove() it must deliver an invalidation shutdown to all DMABUF importi= ng +drivers through move_notify() and synchronously DMA unmap all the MMIO. + +No importing driver can continue to have a DMA map to the MMIO after the +exporting driver has destroyed it's p2p_provider. =20 =20 P2P DMA Support Library --=20 2.51.0