Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

77 participants
6775 discussions

[PATCH net-next v2 0/4] net: devmem: allow rx-buf-size > PAGE_SIZE per binding

by Bobby Eshleman

Every devmem dmabuf binding hands the page_pool PAGE_SIZE niovs today. On NICs that consume one descriptor per netmem, this caps a single RX descriptor at PAGE_SIZE and burns CPU on buffer churn. In this series, we add a bind-time netlink attribute, NETDEV_A_DMABUF_RX_BUF_SIZE, that lets userspace request a larger niov size (power of two >= PAGE_SIZE). Drivers must opt in via queue_mgmt_ops.QCFG_RX_PAGE_SIZE. Selftests use udmabuf, but udmabuf sgtables were previously hardcoded to PAGE_SIZE. This series modifies udmabuf to respect folio sizes in its exported sgtable. The result is that when backing udmabuf with MFD_HUGETLB 2MB pages, the sgtable is populated with 2MB entries, allowing devmem's gen_pool to carve out large (eg. 64K) niovs. Measurements ------------ Setup: kperf devmem RX/TX cuda, 4 flows, 64 MB messages, 60s, dctcp, num-rx-queues=4, dmabuf-rx/tx-size-mb=2048, 10 runs per niov size, mlx5. niov RX dev Gbps RX flow avg Gbps app sys % ----- ---------------- ----------------- ---------------- 4K 300.63 +/- 53.21 75.16 +/- 13.30 54.15 +/- 10.23 16K 321.35 +/- 28.20 80.34 +/- 7.05 41.05 +/- 8.87 32K 347.63 +/- 2.20 86.91 +/- 0.55 44.54 +/- 3.51 64K 332.11 +/- 14.26 83.03 +/- 3.56 35.47 +/- 3.11 RX app sys % drops ~19% from 4K to 64K. kperf support (not yet merged): https://github.com/facebookexperimental/kperf/commit/8837577f920876bce6986e… Signed-off-by: Bobby Eshleman <bobbyeshleman(a)meta.com> --- Changes in v2: - Use NL_SET_ERR_MSG_FMT for sg alignment failure details (Stan) - Keep -E2BIG (not a direct ask, but seemed preferred, Stan) - Update udmabuf commit message and comments explaining why "one sg ent per folio" is useful (Christian) - Set/restore nr_hugepages in py harness (Stan) - Link to v1: https://lore.kernel.org/r/20260603-tcpdm-large-niovs-v1-0-f37a4ac6726c@meta… --- Bobby Eshleman (4): net: devmem: allow rx-buf-size > PAGE_SIZE per dmabuf binding udmabuf: emit one sg entry per pinned folio selftests/net: ncdevmem: add -b option to set rx-buf-size on bind selftests/net: devmem.py: add check_rx_large_niov Documentation/netlink/specs/netdev.yaml | 8 +++ drivers/dma-buf/udmabuf.c | 52 +++++++++++++++++-- include/uapi/linux/netdev.h | 1 + net/core/devmem.c | 51 +++++++++++-------- net/core/devmem.h | 13 +++-- net/core/netdev-genl-gen.c | 5 +- net/core/netdev-genl.c | 19 ++++++- tools/include/uapi/linux/netdev.h | 1 + tools/testing/selftests/drivers/net/hw/config | 1 + tools/testing/selftests/drivers/net/hw/devmem.py | 12 ++++- .../testing/selftests/drivers/net/hw/devmem_lib.py | 58 +++++++++++++++++++++- tools/testing/selftests/drivers/net/hw/ncdevmem.c | 49 ++++++++++++++++-- .../testing/selftests/drivers/net/hw/nk_devmem.py | 11 +++- 13 files changed, 238 insertions(+), 43 deletions(-) --- base-commit: 518d8d0199538a4d6d5e51064044ece71e0c42e7 change-id: 20260602-tcpdm-large-niovs-56523a3a1077 Best regards, -- Bobby Eshleman <bobbyeshleman(a)meta.com>

4 hours, 24 minutes

THE BEST AND LEGITIMATE HACKER IN THE WORLD // GEO COORDINATES RECOVERY HACKER

by Fate Elena

THE BEST AND LEGITIMATE HACKER IN THE WORLD // GEO COORDINATES RECOVERY HACKER Do you want to hire a hacker to solve your problems in various conditions? If you require the services of a genuine hacker and do not have any idea about how to hire a professional hacker online, you are at the right place. There are many cryptocurrency theft cases and schemes currently in circulation in the whole world so it’s important to be careful before investing with any platform. I lost almost all my savings in a fake investment website but I got rescued through the recovery hacker called GEO COORDINATES RECOVERY HACKER as they recovered my stolen funds completely without hassle or hidden fees. This expert retrieved my stolen funds remotely within a few hours as I got notification on my blockchain wallet my funds had been restored. This is the best help I ever got on the internet and I decided to give them a good review about their good job and how quick they are in helping and standing for individuals in tough situations. Kindly contact them if you are in trouble. Email: geovcoordinateshacker(a)gmail.com Website; https://geovcoordinateshac.wixsite.com/geo-coordinates-hack WhatsApp: +1 ( 318 ) 203-3657 )

4 hours, 28 minutes

THE BEST AND LEGITIMATE HACKER IN THE WORLD // GEO COORDINATES RECOVERY HACKER

by Fate Elena

4 hours, 28 minutes

THE BEST AND LEGITIMATE HACKER IN THE WORLD // GEO COORDINATES RECOVERY HACKER

by Fate Elena

4 hours, 29 minutes

Re: [PATCH v3 6/9] vfio/pci: Clean up BAR zap and revocation

by Pranjal Shrivastava

On Wed, Jun 10, 2026 at 04:43:20PM +0100, Matt Evans wrote: > Previously, vfio_pci_zap_bars() (and the wrapper > vfio_pci_zap_and_down_write_memory_lock()) calls were paired with > calls to vfio_pci_dma_buf_move(). > > This commit replaces them with a unified new function, > vfio_pci_zap_revoke_bars() containing both the vfio_pci_dma_buf_move() > and the unmap_mapping_range(), making it harder for callers to omit > one. It adds a wrapper, vfio_pci_lock_zap_revoke_bars(), which takes > the write memory_lock before zapping, and adds a new > vfio_pci_unrevoke_bars() for the re-enable path. > > As of "vfio/pci: Convert BAR mmap() to use a DMABUF", the > unmap_mapping_range() to zap is no longer performed for vfio-pci since > the DMABUFs used for BAR mappings already zap PTEs when the > vfio_pci_dma_buf_move() occurs. > > However, it must be assumed that VFIO drivers which override the .mmap > op could create mappings _not_ backed by DMABUFs. So, the zap is > still performed on revoke if .mmap is overridden, using a new > zap_bars_on_revoke flag. A driver can explicitly opt out; the flag is > cleared by the hisi_acc_vfio_pci driver, since its .mmap just wraps > vfio_pci_core_mmap() and so still uses DMABUFs. > > Signed-off-by: Matt Evans <matt(a)ozlabs.org> > --- > .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 +++ > drivers/vfio/pci/vfio_pci_config.c | 30 ++++---- > drivers/vfio/pci/vfio_pci_core.c | 70 +++++++++++++------ > drivers/vfio/pci/vfio_pci_priv.h | 3 +- > include/linux/vfio_pci_core.h | 1 + > 5 files changed, 73 insertions(+), 39 deletions(-) > > diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > index 86362ec424a5..51990f6d66d5 100644 > --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c > @@ -1692,6 +1692,14 @@ static int hisi_acc_vfio_pci_probe(struct pci_dev *pdev, const struct pci_device > if (ret) > goto out_put_vdev; > > + /* > + * hisi_acc_vfio_pci_mmap() calls down to > + * vfio_pci_core_mmap(), so BAR mappings are still > + * DMABUF-backed. They don't require a zap on revoke, so opt > + * out: > + */ > + hisi_acc_vdev->core_device.zap_bars_on_revoke = false; > + This seems to be happening after we vfio_pci_core_register_device, which could be slightly problematic if another device in the same group races to trigger a hot reset before we can set this to false. Could we initialize this flag before registration instead? > hisi_acc_vfio_debug_init(hisi_acc_vdev); > return 0; > > diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c > index a10ed733f0e3..8bfab0da481c 100644 > --- a/drivers/vfio/pci/vfio_pci_config.c > +++ b/drivers/vfio/pci/vfio_pci_config.c > @@ -590,12 +590,10 @@ static int vfio_basic_config_write(struct vfio_pci_core_device *vdev, int pos, > virt_mem = !!(le16_to_cpu(*virt_cmd) & PCI_COMMAND_MEMORY); > new_mem = !!(new_cmd & PCI_COMMAND_MEMORY); > > - if (!new_mem) { > - vfio_pci_zap_and_down_write_memory_lock(vdev); > - vfio_pci_dma_buf_move(vdev, true); > - } else { > + if (!new_mem) > + vfio_pci_lock_zap_revoke_bars(vdev); > + else > down_write(&vdev->memory_lock); > - } > > /* > * If the user is writing mem/io enable (new_mem/io) and we > @@ -631,7 +629,7 @@ static int vfio_basic_config_write(struct vfio_pci_core_device *vdev, int pos, > *virt_cmd |= cpu_to_le16(new_cmd & mask); > > if (__vfio_pci_memory_enabled(vdev)) > - vfio_pci_dma_buf_move(vdev, false); > + vfio_pci_unrevoke_bars(vdev); > up_write(&vdev->memory_lock); > } > > @@ -712,16 +710,14 @@ static int __init init_pci_cap_basic_perm(struct perm_bits *perm) > static void vfio_lock_and_set_power_state(struct vfio_pci_core_device *vdev, > pci_power_t state) > { > - if (state >= PCI_D3hot) { > - vfio_pci_zap_and_down_write_memory_lock(vdev); > - vfio_pci_dma_buf_move(vdev, true); > - } else { > + if (state >= PCI_D3hot) > + vfio_pci_lock_zap_revoke_bars(vdev); > + else > down_write(&vdev->memory_lock); > - } > > vfio_pci_set_power_state(vdev, state); > if (__vfio_pci_memory_enabled(vdev)) > - vfio_pci_dma_buf_move(vdev, false); > + vfio_pci_unrevoke_bars(vdev); > up_write(&vdev->memory_lock); > } > > @@ -908,11 +904,10 @@ static int vfio_exp_config_write(struct vfio_pci_core_device *vdev, int pos, > &cap); > > if (!ret && (cap & PCI_EXP_DEVCAP_FLR)) { > - vfio_pci_zap_and_down_write_memory_lock(vdev); > - vfio_pci_dma_buf_move(vdev, true); > + vfio_pci_lock_zap_revoke_bars(vdev); > pci_try_reset_function(vdev->pdev); > if (__vfio_pci_memory_enabled(vdev)) > - vfio_pci_dma_buf_move(vdev, false); > + vfio_pci_unrevoke_bars(vdev); > up_write(&vdev->memory_lock); > } > } > @@ -993,11 +988,10 @@ static int vfio_af_config_write(struct vfio_pci_core_device *vdev, int pos, > &cap); > > if (!ret && (cap & PCI_AF_CAP_FLR) && (cap & PCI_AF_CAP_TP)) { > - vfio_pci_zap_and_down_write_memory_lock(vdev); > - vfio_pci_dma_buf_move(vdev, true); > + vfio_pci_lock_zap_revoke_bars(vdev); > pci_try_reset_function(vdev->pdev); > if (__vfio_pci_memory_enabled(vdev)) > - vfio_pci_dma_buf_move(vdev, false); > + vfio_pci_unrevoke_bars(vdev); > up_write(&vdev->memory_lock); > } > } > diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c > index f9636d8f9e2a..5ea0bd4e7876 100644 > --- a/drivers/vfio/pci/vfio_pci_core.c > +++ b/drivers/vfio/pci/vfio_pci_core.c > @@ -319,8 +319,7 @@ static int vfio_pci_runtime_pm_entry(struct vfio_pci_core_device *vdev, > * The vdev power related flags are protected with 'memory_lock' > * semaphore. > */ > - vfio_pci_zap_and_down_write_memory_lock(vdev); > - vfio_pci_dma_buf_move(vdev, true); > + vfio_pci_lock_zap_revoke_bars(vdev); > > if (vdev->pm_runtime_engaged) { > up_write(&vdev->memory_lock); > @@ -406,7 +405,7 @@ static void vfio_pci_runtime_pm_exit(struct vfio_pci_core_device *vdev) > down_write(&vdev->memory_lock); > __vfio_pci_runtime_pm_exit(vdev); > if (__vfio_pci_memory_enabled(vdev)) > - vfio_pci_dma_buf_move(vdev, false); > + vfio_pci_unrevoke_bars(vdev); > up_write(&vdev->memory_lock); > } > > @@ -1256,6 +1255,8 @@ static int vfio_pci_ioctl_set_irqs(struct vfio_pci_core_device *vdev, > return ret; > } > > +static void vfio_pci_zap_revoke_bars(struct vfio_pci_core_device *vdev); > + > static int vfio_pci_ioctl_reset(struct vfio_pci_core_device *vdev, > void __user *arg) > { > @@ -1264,7 +1265,7 @@ static int vfio_pci_ioctl_reset(struct vfio_pci_core_device *vdev, > if (!vdev->reset_works) > return -EINVAL; > > - vfio_pci_zap_and_down_write_memory_lock(vdev); > + down_write(&vdev->memory_lock); > > /* > * This function can be invoked while the power state is non-D0. If > @@ -1277,10 +1278,11 @@ static int vfio_pci_ioctl_reset(struct vfio_pci_core_device *vdev, > */ > vfio_pci_set_power_state(vdev, PCI_D0); > > - vfio_pci_dma_buf_move(vdev, true); > + vfio_pci_zap_revoke_bars(vdev); I'm wondering if this change in behavior is correct? BEFORE this patch the sequence was: 1. zap vma mappings 2. Enter D0 After this patch the sequence becomes 1. Take the lock 2. Enter D0 3. zap vma mappings My worry is if user-space accesses a BAR *during* the transition to D0, it could crash since the mappings still exist during the transition? The old code is immune to it because it removed user-mappings first. Following the discussion from v1 regarding the ordering of vfio_pci_dma_buf_move() and the D0 transition.. while it makes sense to perform the DMABUF revocation/move after the hardware is in D0.. I'm not too confident about moving zap after D0 :/ I mean, sure, the user would just see all Fs on a read and writes will be dropped silently until we are in D0.. but the behaviour before this change was that the user access will fault and hang on the memory_lock instead which ensures that the user observes a consistent dev state.. > + > ret = pci_try_reset_function(vdev->pdev); > if (__vfio_pci_memory_enabled(vdev)) > - vfio_pci_dma_buf_move(vdev, false); > + vfio_pci_unrevoke_bars(vdev); > up_write(&vdev->memory_lock); > > return ret; > @@ -1648,20 +1650,37 @@ ssize_t vfio_pci_core_write(struct vfio_device *core_vdev, const char __user *bu > } Thanks, Praan

7 hours, 16 minutes

Re: [PATCH v3 2/9] vfio/pci: Add a helper to look up PFNs for DMABUFs

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Tuesday, June 16, 2026 2:04 AM > > On 12/06/2026 09:42, Tian, Kevin wrote: > >> From: Matt Evans <matt(a)ozlabs.org> > >> Sent: Wednesday, June 10, 2026 11:43 PM > >> > >> +int vfio_pci_dma_buf_find_pfn(struct vfio_pci_dma_buf *priv, > >> + struct vm_area_struct *vma, > >> + unsigned long address, > >> + unsigned int order, > >> + unsigned long *out_pfn) > >> +{ > >> + /* > >> + * Given a VMA (start, end, pgoffs) and a fault address, > >> + * search the corresponding DMABUF's phys_vec[] to find the > >> + * range representing the address's offset into the VMA, and > >> + * its PFN. > >> + * > >> + * The phys_vec[] ranges represent contiguous spans of VAs > >> + * upwards from the buffer offset 0; the actual PFNs might be > >> + * in any order, overlap/alias, etc. Calculate an offset of > >> + * the desired page given VMA start/pgoff and address, then > >> + * search upwards from 0 to find which span contains it. > >> + * > >> + * On success, a valid PFN for a page sized by 'order' is > >> + * returned into out_pfn. > >> + * > >> + * Failure occurs if: > >> + * - The page would cross the edge of the VMA > >> + * - The page isn't entirely contained within a range > >> + * - We find a range, but the final PFN isn't aligned to the > >> + * requested order. > >> + * > >> + * (Upon failure, the caller is expected to try again with a > >> + * smaller order; the tests above will always succeed for > >> + * order=0 as the limit case.) > >> + * > >> + * It's suboptimal if DMABUFs are created with neigbouring > > > > s/neigbouring/neighboring/ > > Ah, not a typo. :) That is en_GB and AFAIK is permitted. I guess you meant 'neighbouring' and 'neighboring' are both valid. but here lacking a 'h' should be a typo? :) > >> + */ > >> + > >> + const unsigned long pagesize = PAGE_SIZE << order; > >> + unsigned long vma_off = ((vma->vm_pgoff - priv->vma_pgoff_adjust) > >> << > >> + PAGE_SHIFT) & VFIO_PCI_OFFSET_MASK; > >> + unsigned long rounded_page_addr = ALIGN_DOWN(address, > >> pagesize); > >> + unsigned long rounded_page_end = rounded_page_addr + pagesize; > >> + unsigned long page_buf_offset; > >> + unsigned long page_buf_offset_end; > > > > what about "fault_offset[_end]"? page_buf is a bit confusing. > > I went round several times with these names, thanks for the input. Just > tried it out and your suggestion is clearer. > > >> + unsigned long range_buf_offset = 0; > > > > could this be called 'range_start' then the 'range_start' in latter loop > > is renamed to 'phys_start'? > > > > Not strong... just feel such naming helps me understand the logic easier > > Anything that helps helps, thanks. I ended up renaming this to > range_start_offset (as offset is IMHO important). > > I'm a fan of diagrams but this is too large to include in a comment. > But for posterity on the list, and using the new names, an illustration > of a DMABUF with 3 ranges in phys_vec, where a mapping's > faulting page offset lies in range [1]: > > fault_addr--+ > v VMA > +-----------------+----------+-----------------+ > | | Faulting | | > | | (hg)page | | > | | | | > |---- vma_off ---->+-----------------+----------+-----------------+ > | . . > | . . > |--------- fault_offset ------------>. . DMABUF > +-------------------------+---------------------------+--------------+ > | phys_vec[0] | phys_vec[1] . | phys_vec[2] | > | .paddr | . . | | > | .len | . . | | > +-------------------------+---------------------------+--------------+ > 0 : . . : L > |-- range_start_offset -->: . . -->: range_len > : . . : > V . . : > +----------+----------+-----+ > |.paddr | PFN | | > | | | | > | | | | > +----------+----------+-----+ > P > > P = paddr + (fault_offset - range_start_offset) > L = sum(phys_vec[0...2].len) > yes, much clearer now.

7 hours, 36 minutes

Re: [PATCH v3 9/9] vfio/pci: Add mmap() attributes to DMABUF feature

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Wednesday, June 10, 2026 11:43 PM > > A new VFIO feature, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR, is added > to > set CPU-facing memory type attributes for a DMABUF exported from > vfio-pci. These are used for subsequent mmap()s of the buffer. > > There are two attributes supported: > - The default, VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR_NC > - VFIO_DEVICE_FEATURE_DMA_BUF_MEMATTR_WC, which results in WC > PTEs for the DMABUF's BAR region. > > Signed-off-by: Matt Evans <matt(a)ozlabs.org> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>

7 hours, 38 minutes

Re: [PATCH v3 8/9] vfio/pci: Permanently revoke a DMABUF on request

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Wednesday, June 10, 2026 11:43 PM > > Expand the VFIO DMABUF revocation state to three states: > Not revoked, temporarily revoked, and permanently revoked. > > The first two are for existing transient revocation, e.g. across a > function reset, and the DMABUF is put into the last in response to a > new VFIO feature VFIO_DEVICE_FEATURE_DMA_BUF. VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE > > VFIO_DEVICE_FEATURE_DMA_BUF passes a DMABUF by fd and requests that > the DMABUF is permanently revoked. On success, it's guaranteed that ditto > the buffer can never be imported/attached/mmap()ed in future, that > dynamic imports have been cleanly detached, and that all mappings have > been made inaccessible/PTEs zapped. > > This is useful for lifecycle management, to reclaim VFIO PCI BAR > ranges previously delegated to a subordinate client process: The > driver process can ensure that the loaned resources are revoked when > the client is deemed "done", and exported ranges can be safely re-used > elsewhere. probably clarify that re-use by creating a new dmabuf fd as the original one is essentially zombie now. > > +/* Set the DMABUF's revocation status (OK or temporarily/permanently > revoked) */ > +static void vfio_pci_dma_buf_set_status(struct vfio_pci_dma_buf *priv, > + enum vfio_pci_dma_buf_status > new_status) > +{ > + bool was_revoked; > + > + lockdep_assert_held_write(&priv->vdev->memory_lock); > + > + if (priv->status == VFIO_PCI_DMABUF_PERM_REVOKED || > + priv->status == new_status) { > + return; > + } the only interface to request PERM_REVOKED is via the new ioctl. vfio_pci_core_feature_dma_buf_revoke() returns -EBADFD if it's already in PERM_REVOKED. so this check shouldn't be reached, suggesting a warning. > + > + dma_buf_invalidate_mappings(priv->dmabuf); > + dma_resv_wait_timeout(priv->dmabuf->resv, > + DMA_RESV_USAGE_BOOKKEEP, false, > + MAX_SCHEDULE_TIMEOUT); > + dma_resv_unlock(priv->dmabuf->resv); It's existing code but while at it let's make above conditional to the actual revoke path. for unrevoked it's not required given the previous revoke already cleans up everything. otherwise, Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>

7 hours, 39 minutes

Re: [PATCH v3 7/9] vfio/pci: Support mmap() of a VFIO DMABUF

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Wednesday, June 10, 2026 11:43 PM > + > + /* > + * dma_buf_mmap_internal() has asserted that the VMA is > + * contained within the DMABUF size before calling this. > + */ > + > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); > + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); remove the blank line. Reviewed-by: Kevin Tian <kevin.tian(a)intel.com>

7 hours, 44 minutes

Re: [PATCH v3 6/9] vfio/pci: Clean up BAR zap and revocation

by Tian, Kevin

> From: Matt Evans <matt(a)ozlabs.org> > Sent: Wednesday, June 10, 2026 11:43 PM > > Previously, vfio_pci_zap_bars() (and the wrapper > vfio_pci_zap_and_down_write_memory_lock()) calls were paired with > calls to vfio_pci_dma_buf_move(). > > This commit replaces them with a unified new function, > vfio_pci_zap_revoke_bars() containing both the vfio_pci_dma_buf_move() > and the unmap_mapping_range(), making it harder for callers to omit > one. It adds a wrapper, vfio_pci_lock_zap_revoke_bars(), which takes > the write memory_lock before zapping, and adds a new > vfio_pci_unrevoke_bars() for the re-enable path. It's unusual to have three verbs (lock/zap/revoke) in one function name. I wonder whether it's simpler to have: vfio_pci_zap_bars_locked() // caller already holds the lock vfio_pci_zap_bars() 'revoke' is just a side-effect of 'zap', not necessarily to highlight it in the name. > > As of "vfio/pci: Convert BAR mmap() to use a DMABUF", the > unmap_mapping_range() to zap is no longer performed for vfio-pci since > the DMABUFs used for BAR mappings already zap PTEs when the > vfio_pci_dma_buf_move() occurs. > > However, it must be assumed that VFIO drivers which override the .mmap > op could create mappings _not_ backed by DMABUFs. So, the zap is > still performed on revoke if .mmap is overridden, using a new > zap_bars_on_revoke flag. A driver can explicitly opt out; the flag is > cleared by the hisi_acc_vfio_pci driver, since its .mmap just wraps > vfio_pci_core_mmap() and so still uses DMABUFs. the cost of unmap_mapping_range() is trivial when there is no mmap on the device fd. so it could be simpler by always doing: vfio_pci_dma_buf_move(); unmap_mapping_range(); and remove the flag.

7 hours, 47 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig