From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fhigh-b7-smtp.messagingengine.com (fhigh-b7-smtp.messagingengine.com [202.12.124.158]) (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 0526A311969; Fri, 1 May 2026 22:19:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=202.12.124.158 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777673964; cv=none; b=UxA6TEaYhCGZJa1tyfKX0vCe/0R5E3mRgQ+ULWCeRxW9jSeauSx9m7pGm8u2RpKY+AhV/xYZLnAmN0z8yaOQTjW8v4nFzczyr7exh0Dq/QbnpIsnkmohQwIBaHD4/rtcjifa8PM9rXhvGg0SvkUL5FdaBKU3AH9VjwvS/blA9R8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777673964; c=relaxed/simple; bh=LKLmpAMvdy7nhyII+neC4/sH0Z65su8gdM107KwQx8k=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=G/kaolrcDO9LYlQ0iF29zBHOHDGHZv6omtlvexgHjrj0hpJIHRB7pNz/fCYEBQVjc7EZg+uHwpat1mtaelxwL+EiB/M3pakznXXiLLuvCPTj7nGEHj/POCMX6hG0bxTOF8II6qyG/m+uqGVWDSTctlQoFUKrlNp1eUeTivq2g4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shazbot.org; spf=pass smtp.mailfrom=shazbot.org; dkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org header.b=Z36rFCSV; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=Riv28Dn2; arc=none smtp.client-ip=202.12.124.158 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=shazbot.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=shazbot.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=shazbot.org header.i=@shazbot.org header.b="Z36rFCSV"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="Riv28Dn2" Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id EEA127A0078; Fri, 1 May 2026 18:19:18 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Fri, 01 May 2026 18:19:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shazbot.org; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1777673958; x=1777760358; bh=4TX/vtHUA9w5SLfj0GTrWfQ85zbl7VX0Zm2z9iybBGg=; b= Z36rFCSV/QHmdMLY8t8AOreKTfAXJWjSgrmCwCpHa9+ReT7y36fgcR5pc5+GEqDS eLpXfKzpd0Pc5TaH6ae90SgtPzwSlgr89CNZqPRsW47EsnsrIX+eViySl4rlJXJD 0F2itZ57gCSkpgtOJv7K6SMJGOfORF01ic1R15jRI1L6IZZIEEM5PxD8/BsWu1/S eyBik5hXWGwGMEDvebHDpYuvooohhzBSUWUlWqxW5QVsSx9q0fx/UddnaEJHV3aT RB8FAxyZIsh4OjFeHxAaN+E/dhHafNo39QJbQlYa8fMtqJQ6+32I4TlwfypNBE7h HQ5Kpv9hq7/KDnu1Km7UMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1777673958; x= 1777760358; bh=4TX/vtHUA9w5SLfj0GTrWfQ85zbl7VX0Zm2z9iybBGg=; b=R iv28Dn26iAUXL2ry8P1je31g/3uECfkks3pwYk9h65HngH0Uy4tOs8zDdqIm3hTs 2g+1rC0b6Eab1EBcDdcko4IpzoO3iQl8O4VlqgECyUO/TDmw6G6xF09vGFwoDb4w n6yPBJR9BwpOqX0r6Tzsq7S85jq8xcWXZtgS+i6nWtpLzWCod1Ql082fOt+qrApx LA082YBqLFDO/c1RehIIZ+KLdEViXvdJm2aFqGfN5eGh2PZHZKlZlQROnqIBPL3Y /RT8E42WicUOqDnfMP8MAFa0nnXc6BU02LBH82hdlnq1iUNOWI3mc8HHu2dO0fZl WtInGVcI42IirGJLw2KWQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdeludefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpeffhffvvefukfgjfhfogggtgfesthejredtredtvdenucfhrhhomheptehlvgigucgh ihhllhhirghmshhonhcuoegrlhgvgiesshhhrgiisghothdrohhrgheqnecuggftrfgrth htvghrnhepvdekfeejkedvudfhudfhteekudfgudeiteetvdeukedvheetvdekgfdugeev ueeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hlvgigsehshhgriigsohhtrdhorhhgpdhnsggprhgtphhtthhopedvtddpmhhouggvpehs mhhtphhouhhtpdhrtghpthhtohepmhgrthhtvghvsehmvghtrgdrtghomhdprhgtphhtth hopehlvghonheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepjhhgghesnhhvihguihgr rdgtohhmpdhrtghpthhtoheprghmrghsthhrohesfhgsrdgtohhmpdhrtghpthhtoheptg hhrhhishhtihgrnhdrkhhovghnihhgsegrmhgurdgtohhmpdhrtghpthhtohepmhhnghih rggurghmsegrmhgriihonhdruggvpdhrtghpthhtohepughmrghtlhgrtghksehgohhogh hlvgdrtghomhdprhgtphhtthhopegsjhhorhhnsehkvghrnhgvlhdrohhrghdprhgtphht thhopehsuhhmihhtrdhsvghmfigrlheslhhinhgrrhhordhorhhg X-ME-Proxy: Feedback-ID: i03f14258:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 1 May 2026 18:19:16 -0400 (EDT) Date: Fri, 1 May 2026 16:19:15 -0600 From: Alex Williamson To: Matt Evans Cc: Leon Romanovsky , Jason Gunthorpe , Alex Mastro , Christian =?UTF-8?B?S8O2bmln?= , Mahmoud Adam , David Matlack , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Sumit Semwal , Kevin Tian , Ankit Agrawal , Pranjal Shrivastava , Alistair Popple , Vivek Kasireddy , , , , , , alex@shazbot.org Subject: Re: [PATCH 4/9] vfio/pci: Convert BAR mmap() to use a DMABUF Message-ID: <20260501161915.75525c15@shazbot.org> In-Reply-To: <20260416131815.2729131-5-mattev@meta.com> References: <20260416131815.2729131-1-mattev@meta.com> <20260416131815.2729131-5-mattev@meta.com> X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 16 Apr 2026 06:17:47 -0700 Matt Evans wrote: > Convert the VFIO device fd fops->mmap to create a DMABUF representing > the BAR mapping, and make the VMA fault handler look up PFNs from the > corresponding DMABUF. This supports future code mmap()ing BAR > DMABUFs, and iommufd work to support Type1 P2P. > > First, vfio_pci_core_mmap() uses the new > vfio_pci_core_mmap_prep_dmabuf() helper to export a DMABUF > representing a single BAR range. Then, the vfio_pci_mmap_huge_fault() > callback is updated to understand revoked buffers, and uses the new > vfio_pci_dma_buf_find_pfn() helper to determine the PFN for a given > fault address. > > Now that the VFIO DMABUFs can be mmap()ed, vfio_pci_dma_buf_move() and > vfio_pci_dma_buf_cleanup() need to zap PTEs on revocation and cleanup > paths. > > CONFIG_VFIO_PCI_CORE now unconditionally depends on > CONFIG_DMA_SHARED_BUFFER. CONFIG_VFIO_PCI_DMABUF remains, to > conditionally include support for VFIO_DEVICE_FEATURE_DMA_BUF, and > depends on CONFIG_PCI_P2PDMA. > > Signed-off-by: Matt Evans > --- > drivers/vfio/pci/Kconfig | 3 +- > drivers/vfio/pci/Makefile | 3 +- > drivers/vfio/pci/vfio_pci_core.c | 86 ++++++++++++++++++------------ > drivers/vfio/pci/vfio_pci_dmabuf.c | 14 +++++ > drivers/vfio/pci/vfio_pci_priv.h | 11 +--- > 5 files changed, 71 insertions(+), 46 deletions(-) > > diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig > index 296bf01e185e..2074f2a941e1 100644 > --- a/drivers/vfio/pci/Kconfig > +++ b/drivers/vfio/pci/Kconfig > @@ -6,6 +6,7 @@ config VFIO_PCI_CORE > tristate > select VFIO_VIRQFD > select IRQ_BYPASS_MANAGER > + select DMA_SHARED_BUFFER > > config VFIO_PCI_INTX > def_bool y if !S390 > @@ -56,7 +57,7 @@ config VFIO_PCI_ZDEV_KVM > To enable s390x KVM vfio-pci extensions, say Y. > > config VFIO_PCI_DMABUF > - def_bool y if VFIO_PCI_CORE && PCI_P2PDMA && DMA_SHARED_BUFFER > + def_bool y if PCI_P2PDMA But here we introduce the call chain: vfio_pci_core_mmap() -> vfio_pci_core_mmap_prep_dmabuf() -> pcim_p2pdma_provider() Where pcim_p2pdma_provider() requires PCI_P2PDMA. So honestly, VFIO_PCI_CORE depends on PCI_P2PDMA. I think that's a pretty significant regression. Exporting dma-bufs from vfio-pci is a feature, but mmap of MMIO BARs is a legacy requirement. That legacy requirement now depends on PCI_P2PDMA, which depends on 64BIT and ZONE_DEVICE. It's possible that our 32-bit support is already broken and we can easily codify it in Kconfig. We should check. Otherwise it seems pretty harsh to drop it without notice, or make it fundamentally broken by exposing mmap support flags for regions where mmap is no longer available. ZONE_DEVICE is harder, it seems like it's possible there could be minimal 64-bit custom kernel configs where vfio-pci currently works without ZONE_DEVICE. We might be headed to this impasse already as dma-buf is required to have feature-complete compatibility with iommufd, but I had hoped we'd be able to manage that with full legacy functionality through the transition. Thanks, Alex