From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 6CA5E343D83 for ; Thu, 30 Apr 2026 16:47:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=67.231.145.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777567677; cv=none; b=S+4S72ms7HvbEDyOvXimx2XmEpmrE6KRm1xd26r/b2nMQknPVGNBGHjcPkMFzZ1IOXPEifgEnFrn+mYFWh+n6k7Cf14ztWme/7BcOPxIRrJ294NwH0GI3+71ZeE1BSq7p6/xMRSkzO2VGMKfX9W6xvHbvgM6Lhbfeee3D9EWem4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777567677; c=relaxed/simple; bh=cSGNZ8wgbO7X87rwVZjWUPh3PFb7JnuVVs+4c9CzkS4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=G9WRb2EEmaX9+XsWB7NS0HFxLU6vPCdZjUfibMuklRzyjo1n41waE7o8jhgIiCjx3RYZ2m4hSSiM3z4K5NCFeIS2fj9p0sZqjN5az6ARJoFrF7s+ug3/sXshBHTGdLu3HtKCAujeyMB23+khAcSu/oUEoKUMOSJSwlzgbUPsg08= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=meta.com; spf=pass smtp.mailfrom=meta.com; dkim=pass (2048-bit key) header.d=meta.com header.i=@meta.com header.b=VmzmDuLo; arc=none smtp.client-ip=67.231.145.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=meta.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=meta.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=meta.com header.i=@meta.com header.b="VmzmDuLo" Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 63UDB5Xl4182194 for ; Thu, 30 Apr 2026 09:47:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=s2048-2025-q2; bh=CXvj6rmLtU+yqG7K5nb8uAhPCFMrTB1Lg0tTO/8UY38=; b=VmzmDuLofwCN XcDBoa+sLJlHhfy6vjpvEjX9zOHYSohipMJKuWABb0/tFAgCYvUKYRmq1VYJYrm+ YyffbepmXjCagGPySLIrmaJ5SWJEIM+OBHitW/S1gBzRFsRT6oc2SxOGzvzDzjUw 92vNwrtouQ3cYeinUfudEAWZWLyl6zwoda8rflkF4cjAWAFZesr61T3Px2BTqwDf hF6OXYCAbJd2TYHTf+LHNX+8OiYQxHtTHKnZa33UUllCmQi1/95LKvMZ1J2xd6Ve 2O6g8ywmcBylHs0F9CFe3Ys6hZVRNSwGu5ttT4tnlutyOtT7x9qVVAEtvsvTkoVC pXi+P7srPw== Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by mx0a-00082601.pphosted.com (PPS) with ESMTPS id 4drsn3behq-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Thu, 30 Apr 2026 09:47:55 -0700 (PDT) Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-48a5952c635so10960675e9.2 for ; Thu, 30 Apr 2026 09:47:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777567674; x=1778172474; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CXvj6rmLtU+yqG7K5nb8uAhPCFMrTB1Lg0tTO/8UY38=; b=TGa5yXd6cwz7BxiW++n4rdEnNJscWERxRhRVyE6rbZBQX1xMczbp4sLjTrGOqa1+/6 pD4M+IimRJSrDL31ek83NF5xR7jV4WzCXRa4D2280yAndRo0KdLmJYB0MqW5J3TFL4uX XQN97NfpHh4jq0S6t3JGn6QD/O42JWzlGvCE74IVXqMjc/lIygo1sPPMVSnClmR7KkSp onUdMYQywIJSdMWPIdJmi8i2v4ppQ3PxJPUVfV2tnd86ThwztwixArd1Hsd5vy/VY/d4 jcTO1Cd1a5qn5QtU2SUU0Xy357GQlDd5fqTYOlbUxM4FMB7ykGhTioMUDe7m2MWqkxro bguQ== X-Forwarded-Encrypted: i=1; AFNElJ+JCq9MOSjtU84r+8NyZuMHgpjix5IN4FgPnBaGsEMycn0pg+HBGGVVOdNsHRWxoJyy2PE2L4JS2tyyEjo=@vger.kernel.org X-Gm-Message-State: AOJu0YwrRUzUike/ZZiBOxPLjnfrrzfu/4qxdRMInrvEktV4BUNGF+Rf nLVYcWaLvtP+tFqe4zZUFkb8owN2Q6A3CaNzpdu0EJS4SU59YH87qJIjYm15+5OkE6K861safpg g37Wcy5hd+8l9/R8/Fy4pX33H8WK2iaG+Bjeb6AnuZdjry/3ENJ9u8NJGFLmxVZdR X-Gm-Gg: AeBDiesFjYase/QaSCo/mYjLpBtwfnn74Z2e7aOhbEYVEE7ouorZqLekVq3CTFaAR9q k5p0ElnZKlr9Ne3LbXOJBdwOFdYvxkx7B6YRKM87wHXUlSq/RRHUA3ftXLr6Gg5VM9DPIArUYJo L0GHCBFb66BIn3jmdnwc0M7J0gNq7KQnT6lBT4uELoJ1Uubw9vm13SDB8IxMDTzTMlmecL+xjby WB7On/b72rRYvJeu1chYB6Kg8v+97gVd4O8YGOlNOb2eQNYOTvPpu55nQGy/xsAWj0Wgv5dhjtY uUsF5lOqlT+iq6pMuK+z/jcgCWgGZI543pAdhW6hRO0xLCs6vyct7901uIMJmd3L5z6L678ZDXl hKja1EN98IHFOGzcKCBAlnIN3rMLD+1j1YQUMm1oBzemJ4Gdlij8aRmCTroUyVDhSVl/EVZEhAL DQ X-Received: by 2002:a05:600c:8483:b0:487:2671:fb8f with SMTP id 5b1f17b1804b1-48a83d73324mr65498755e9.8.1777567673950; Thu, 30 Apr 2026 09:47:53 -0700 (PDT) X-Received: by 2002:a05:600c:8483:b0:487:2671:fb8f with SMTP id 5b1f17b1804b1-48a83d73324mr65498015e9.8.1777567673394; Thu, 30 Apr 2026 09:47:53 -0700 (PDT) Received: from ?IPV6:2a03:83e0:1126:4:10fb:be93:502f:b7be? ([2620:10d:c092:500::4:5cf3]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a822c82f2sm75353315e9.11.2026.04.30.09.47.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2026 09:47:52 -0700 (PDT) Message-ID: Date: Thu, 30 Apr 2026 17:47:49 +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 3/9] vfio/pci: Add a helper to create a DMABUF for a BAR-map VMA Content-Language: en-GB To: Jason Gunthorpe Cc: Alex Williamson , Leon Romanovsky , Alex Mastro , =?UTF-8?Q?Christian_K=C3=B6nig?= , Mahmoud Adam , David Matlack , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Sumit Semwal , Kevin Tian , Ankit Agrawal , Pranjal Shrivastava , Alistair Popple , Vivek Kasireddy , 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 References: <20260416131815.2729131-1-mattev@meta.com> <20260416131815.2729131-4-mattev@meta.com> <20260424182426.GG3444440@nvidia.com> From: Matt Evans In-Reply-To: <20260424182426.GG3444440@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNDMwMDE3MiBTYWx0ZWRfXwGdPZqOFRVf0 QY2seSf3jATn1QoTTBmP+PFvf5kzX8UjHSuJkVkb23Fj+N0+rtBO0ttm0QlohoOk4X2DAk5NdM9 +Q4AYlCIMDnZ0hPGgk7pyy8dTDTv2O/UGFq56J1/sIxVBv1jqrfTy6sJPrGlylwtUchA7cmm5AT R9lQ9izoMSPaWvdWbgD734avbQpK24RT/fMhC/yj5QyV7Dukkk5CGcITpu0p9uvCx728ty3dXMJ iX+fFQEm9ioPGrZkNYBBVdgkcg9RDcp0sJpYlM3CaUZ0xNS1K6e5ZL8kIt5j33MoyBls4lYKlE7 NzeCYHJ1VEHe6/btwz3K6zz6oODHxX0SXXWLX8BU7c/ejbZzuP5x1wmQxbnSjmr2w3w1Cq4FO9S S4Js2BZzupW89fHNOGJWx6QUQOeCu6DTeEWlXMSVrjE1NdHDQsKkTjikA+OjVnwXVepeqiO/rTV iCDOTVUdPf+zdzwpwKA== X-Authority-Analysis: v=2.4 cv=NoDhtcdJ c=1 sm=1 tr=0 ts=69f387bb cx=c_pps a=Q4jRaax7EcWM5fECTC1wcQ==:117 a=Dv35txUGz5gI0hTa:21 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=A5OVakUREuEA:10 a=VkNPw1HP01LnGYTKEx00:22 a=7x6HtfJdh03M6CCDgxCd:22 a=tpM8CJlwf7uhpglF1g9U:22 a=nxdftAbHouV8PAc5HfQA:9 a=QEXdDO2ut3YA:10 a=nJq5_VNI1X7IEIKzvdHs:22 X-Proofpoint-GUID: 2FGc2HvuA9Pghliabv-o75Ye7lZcilUo X-Proofpoint-ORIG-GUID: 2FGc2HvuA9Pghliabv-o75Ye7lZcilUo X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-04-30_04,2026-04-30_02,2025-10-01_01 Hi Jason, On 24/04/2026 19:24, Jason Gunthorpe wrote: > > On Thu, Apr 16, 2026 at 06:17:46AM -0700, Matt Evans wrote: >> +int vfio_pci_core_mmap_prep_dmabuf(struct vfio_pci_core_device *vdev, >> + struct vm_area_struct *vma, >> + u64 phys_start, u64 req_len, >> + unsigned int res_index) >> +{ >> + struct vfio_pci_dma_buf *priv; >> + const unsigned int nr_ranges = 1; >> + int ret; >> + >> + priv = kzalloc_obj(*priv); >> + if (!priv) >> + return -ENOMEM; >> + >> + priv->phys_vec = kzalloc_obj(*priv->phys_vec); >> + if (!priv->phys_vec) { >> + ret = -ENOMEM; >> + goto err_free_priv; >> + } >> + >> + /* >> + * The mmap() request's vma->vm_offs might be non-zero, but >> + * the DMABUF is created from _offset zero_ of the BAR. The >> + * portion between zero and the vm_offs is inaccessible >> + * through this VMA, but this approach keeps the >> + * /proc//maps offset somewhat consistent with the >> + * pre-DMABUF code. Size includes the offset portion. > > I'm not sure I understand this comment? > > For the old path vm_pgoff for byte 0 of the bar starts at some large > offset > > For the new path vm_pgoff for byte 0 of the first range starts at 0 Glad you asked. :) This is trying to achieve keeping /proc//maps (or similar) somewhat as informative as pre-DMABUF BAR mmap, in terms of keeping the VMA vm_offs column useful. Before this patch, say you mmap() two slices A and B of the same BAR: struct vfio_region_info bar_region; vm_a = mmap(0, 0x1000, ..., device_fd, bar_region.offset + 0); vm_b = mmap(0, 0x1000, ..., device_fd, bar_region.offset + 0x4000); ...you'd see something like this in /proc/blah/maps: fffff4000000-fffff4001000 rw-s 10000000000 00:07 148 /dev/vfio/devices/vfio0 fffff5000000-fffff5001000 rw-s 10000004000 00:07 148 /dev/vfio/devices/vfio0 It's nice being able to tell the actual BAR offset (within the VFIO_PCI_OFFSET_MASK, i.e I _don't_ mean the synthetic region index offset). For vm_b, if we create the DMABUF to begin from the start of the actually-mapped slice phys = pci_resource_start(pdev, index) + (vma->vm_pgoff << PAGE_SHIFT) then the VMA's vm_offs would need to be thunked back down to 0 (since the fault handler then treats vm_b + 0 as the first byte of the DMABUF). That works/adds up, but then the vm_offs of both VMAs A & B both have offset 0, and it's harder to differentiate in /proc/blah/maps. An example from the later patch "vfio/pci: Provide a user-facing name for BAR mappings" naming is: ffffb8070000-ffffbc040000 rw-s 00030000 00:0b 5 /dmabuf:vfio0:0000:00:03.0/1 ffffbc140000-ffffbc240000 rw-s 00000000 00:0b 2 /dmabuf:vfio0:0000:00:03.0/0 We could possibly stash the original offset somewhere and then render it in the name string, but the name's already about the max size and using the existing vm_offs column is nicer IMO, doesn't need a new field, etc. I need to work on this comment then! What this is trying to say is that the DMABUF is made artificially larger than the part that is visible through the VMA. I.e. the DMABUF starts at the beginning of the BAR and so an mmap for offset +0x4000 for 0x1000 bytes starts at 0 and the VMA sees 0x4000-0x5000. >> + * This differs from an mmap() of an explicitly-exported >> + * DMABUF which is an arbitrary slice of the BAR, would be >> + * created with the desired offset+size, and would usually be >> + * mmap()ed with pgoff = 0. >> + * >> + * Both are equivalent and vfio_pci_dma_buf_find_pfn() finds >> + * the same PFNs. >> + */ >> + priv->vdev = vdev; >> + priv->nr_ranges = nr_ranges; >> + priv->size = (vma->vm_pgoff << PAGE_SHIFT) + req_len; > > And why is size being calculated from pgoff ? This is the part that makes the size the requested size plus the invisible portion before the VMA starts (equal to an extra 0x4000 in the example above, distance from offset 0). Thanks, Matt PS: Thanks also for the other reviews!