From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) (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 5E5613CDBAB; Mon, 15 Jun 2026 15:33:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=150.107.74.76 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781537633; cv=none; b=F/WsE1p5AlzupGkUV9WM0MXUk2nLGz7F3XCyHNBtPeLD6FhEPwGEA4D0XZMtLDt0/l1jrpqOqdXQeA0HU9EHgGCjcPlBeij8yuUzvvr8V+HX/KWY0hYuLM9GppM3nus2aLPBFreX4otjoEISk23bLlxlCtZzWGPvCn2xhmF+wS4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781537633; c=relaxed/simple; bh=FwxUmCchTPPVy+MqSPLw6SfDb92khsiQLvMLplEv0E0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OaGIDB28KCRkavXZh/PdnlkRGJ8UImSfjuwTrGkzeqUI7JHzv4A1FoHo4x4dF8AoOFoWx7oSuNKmYQb83nZm61wYV4WZAWBtlRz01Jb0JQ0/nypEqRCKkCJhbCWt4WZaxD0qZGA0jE9SrX+psw6cMJSe/rA558kNg7/BfM8jErs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ozlabs.org; spf=pass smtp.mailfrom=ozlabs.org; dkim=pass (2048-bit key) header.d=ozlabs.org header.i=@ozlabs.org header.b=S1wL0MJo; arc=none smtp.client-ip=150.107.74.76 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ozlabs.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ozlabs.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ozlabs.org header.i=@ozlabs.org header.b="S1wL0MJo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ozlabs.org; s=201707; t=1781537627; bh=1mJsClNx/G2flqy/GWs9bnUaqG6Fe9NMYeb2HFZgaHI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=S1wL0MJo4k35FFb3jGunM7ez67P3C13pBFUQhx1CVwaMa+OOas/gpBx2h/mGl7bun wLSGEUIxqaJ70kXp2tQc06/50OxM8WBbx0J2voXpFPI7/yHSK0tMaf1p7l/Shp2d4A F6XsWHRZiWAYgdifWpXvUOZlIHHqks3cuQEzAlAFVn9gwKh22hIMBo5ljbzwr1ee7H qvUXavgqIh+Kf2+A9Ky13oPg1PT9zf/jsQ5wWudAE9X2k4y6o57ky+Hccum1Vn7S6m +wM3Fuf0TgZM5onsu+l/KYyQ5RoIvoqqW47xsHPMaUEg/3eUf5Rt7z8lL7XS4LG+e7 3WQJKk2t+De9Q== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client did not present a certificate) by mail.ozlabs.org (Postfix) with ESMTPSA id 4gfDfr2149z4wT4; Tue, 16 Jun 2026 01:33:39 +1000 (AEST) Message-ID: Date: Mon, 15 Jun 2026 16:33:35 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/9] vfio/pci: Convert BAR mmap() to use a DMABUF Content-Language: en-GB To: "Tian, Kevin" Cc: Alex Williamson , Leon Romanovsky , Jason Gunthorpe , Alex Mastro , =?UTF-8?Q?Christian_K=C3=B6nig?= , Bjorn Helgaas , Logan Gunthorpe , Mahmoud Adam , David Matlack , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Sumit Semwal , Ankit Agrawal , Pranjal Shrivastava , Alistair Popple , "Kasireddy, Vivek" , "linux-kernel@vger.kernel.org" , "linux-media@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "linaro-mm-sig@lists.linaro.org" , "kvm@vger.kernel.org" , "linux-pci@vger.kernel.org" References: <20260610154327.37758-1-matt@ozlabs.org> <20260610154327.37758-5-matt@ozlabs.org> From: Matt Evans In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Kevin, On 12/06/2026 09:46, Tian, Kevin wrote: >> From: Matt Evans >> Sent: Wednesday, June 10, 2026 11:43 PM >> >> 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() >> zaps PTEs (used on the revocation and cleanup paths). >> >> CONFIG_VFIO_PCI_CORE now unconditionally depends on >> CONFIG_DMA_SHARED_BUFFER and CONFIG_PCI_P2PDMA_CORE. The >> CONFIG_VFIO_PCI_DMABUF feature conditionally includes support for >> VFIO_DEVICE_FEATURE_DMA_BUF, depending on the availability of >> CONFIG_PCI_P2PDMA. >> >> Signed-off-by: Matt Evans > > Reviewed-by: Kevin Tian > > with a nit: > >> - vma->vm_private_data = vdev; >> + /* >> + * Create a DMABUF with a single range corresponding to this >> + * mapping, and wire it into vma->vm_private_data. The VMA's >> + * vm_file becomes that of the DMABUF, and the DMABUF takes >> + * ownership of the VFIO device file (put upon DMABUF >> + * release). This maintains the behaviour of a live VMA >> + * mapping holding the VFIO device file open. >> + */ >> + ret = vfio_pci_core_mmap_prep_dmabuf(vdev, vma, >> + pci_resource_start(pdev, index), >> + req_len, index); > > the comment is redundant as it's about internal logic of the callee > and is well covered by the comment there. Thanks on both points! I see what you mean, removed. Matt