From mboxrd@z Thu Jan 1 00:00:00 1970 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 56C1B1DE4CD; Wed, 19 Nov 2025 20:45:46 +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=1763585146; cv=none; b=nguCEI8d0P0FNGn69GxiRwBsyZStbeB/dmgIWLMFkJCrcPhTgXyaS8toMe+bkAgV2HPiowfsEEKrVuAPunL2tUDmlwIV+TYGDUb24jFEIAq7vIx4EDPfsWALQ6PpayXBEtfwB+ldzMWI+nRGzV2R5ER+rjK+JqQh6uczYIUhVvM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763585146; c=relaxed/simple; bh=5rI8lrrVbFn1InvbQielmCucdPk01bWsAxmwyIxRJJc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RJuSyct+GPCygQk9Zw98w/rjga6nd4WpXX01vrfL0EG2EmHE6o7proW66pZeAB6TdltHHc/EDflieot5dAVXiJM3rmqFzrFmfH4INC2eQZan8StqfBlSzURmKC3lFKiFnWheXWE9cC3LhidW/22NRHSDH2daT+2l3YSD+tGizT8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qlv5a0X0; 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="qlv5a0X0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05F3FC4CEF5; Wed, 19 Nov 2025 20:45:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763585145; bh=5rI8lrrVbFn1InvbQielmCucdPk01bWsAxmwyIxRJJc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=qlv5a0X0ngRKyFh2JKVmpc2TkyYK/DU2m5BSvUPEl7BnF5Z4h3h/m+RqO7z1bx61m rbyyfMoS9aqKBh0aUmaaII2BVk6WpQkAzGGpg1rUG+s8HZmAW8WSgoYrh4VjU5XyVE cn3LgrCO1dpfJBw5cCJ/USdlN3JLkb+DpB22klLCEqHAbG4qjTuayYPjr+pzzDi4EO R0Qx5aJ2BOOXu+TPpbSpmwtVpBrFTUylK5laErKZm5ellYru+TJRCMyV7sgWpV4Qxc Y4Mw7ZQsZniCIYFf6yWIotwra9fYcCXVMUXRBjbCK8S0k+X0tqBTMuTL7f8E/JttUG kQjOcbKaf5FSw== Date: Wed, 19 Nov 2025 22:45:41 +0200 From: Leon Romanovsky To: Jason Gunthorpe Cc: Christian =?iso-8859-1?Q?K=F6nig?= , Bjorn Helgaas , Logan Gunthorpe , Jens Axboe , Robin Murphy , Joerg Roedel , Will Deacon , Marek Szyprowski , Andrew Morton , Jonathan Corbet , Sumit Semwal , Kees Cook , "Gustavo A. R. Silva" , Ankit Agrawal , Yishai Hadas , Shameer Kolothum , Kevin Tian , Alex Williamson , 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: Re: [PATCH v8 05/11] PCI/P2PDMA: Document DMABUF model Message-ID: <20251119204541.GN18335@unreal> References: <20251111-dmabuf-vfio-v8-0-fd9aa5df478f@nvidia.com> <20251111-dmabuf-vfio-v8-5-fd9aa5df478f@nvidia.com> <9798b34c-618b-4e89-82b0-803bc655c82b@amd.com> <20251119133529.GL17968@ziepe.ca> <20251119194506.GS17968@ziepe.ca> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251119194506.GS17968@ziepe.ca> On Wed, Nov 19, 2025 at 03:45:06PM -0400, Jason Gunthorpe wrote: > On Wed, Nov 19, 2025 at 03:06:18PM +0100, Christian König wrote: > > On 11/19/25 14:35, Jason Gunthorpe wrote: > > > On Wed, Nov 19, 2025 at 10:18:08AM +0100, Christian König wrote: > > >>> +As this is not well-defined or well-supported in real HW the kernel defaults to > > >>> +blocking such routing. There is an allow list to allow detecting known-good HW, > > >>> +in which case P2P between any two PCIe devices will be permitted. <...> > > The documentation makes it sound like DMA-buf is limited to not > > using struct pages and direct I/O, but that is not true. > > Okay, I see what you mean, the intention was to be very strong and say > if you are not using struct pages then you must using DMABUF or > something like it to control lifetime. Not to say that was the only > way how DMABUF can be used. > > Leon let's try to clarify that a bit more diff --git a/Documentation/driver-api/pci/p2pdma.rst b/Documentation/driver-api/pci/p2pdma.rst index 32e9b691508b..280673b50350 100644 --- a/Documentation/driver-api/pci/p2pdma.rst +++ b/Documentation/driver-api/pci/p2pdma.rst @@ -156,7 +156,8 @@ Usage With DMABUF ================= DMABUF provides an alternative to the above struct page-based -client/provider/orchestrator system. In this mode the exporting driver will wrap +client/provider/orchestrator system and should be used when struct page +doesn't exist. In this mode the exporting driver will 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 > > Jason