Hello Vivek,
On 12/23/25 21:43, Kasireddy, Vivek wrote:
Hi Shameer, Cedric,
Subject: [PATCH 3/3] hw/vfio/region: Create dmabuf for PCI BAR per region
From: Nicolin Chen <[email protected]>
Linux now provides a VFIO dmabuf exporter to expose PCI BAR memory for
P2P
use cases. Create a dmabuf for each mapped BAR region after the mmap is
set
up, and store the returned fd in the region's RAMBlock. This allows QEMU
to
pass the fd to dma_map_file(), enabling iommufd to import the dmabuf and
map
the BAR correctly in the host IOMMU page table.
If the kernel lacks support or dmabuf setup fails, QEMU skips the setup
and continues with normal mmap handling.
Signed-off-by: Nicolin Chen <[email protected]>
Signed-off-by: Shameer Kolothum <[email protected]>
---
hw/vfio/region.c | 57
+++++++++++++++++++++++++++++++++++++++++++-
hw/vfio/trace-events | 1 +
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/hw/vfio/region.c b/hw/vfio/region.c
index b165ab0b93..6949f6779c 100644
--- a/hw/vfio/region.c
+++ b/hw/vfio/region.c
@@ -29,6 +29,7 @@
#include "qemu/error-report.h"
#include "qemu/units.h"
#include "monitor/monitor.h"
+#include "system/ramblock.h"
#include "vfio-helpers.h"
/*
@@ -238,13 +239,52 @@ static void vfio_subregion_unmap(VFIORegion
*region, int index)
region->mmaps[index].mmap = NULL;
}
+static int vfio_region_create_dma_buf(VFIORegion *region)
Would it make sense to consolidate this implementation with the one from my
series:
https://lore.kernel.org/qemu-devel/[email protected]/
so that it is a bit more generic and can also be invoked from outside of VFIO?
I would prefer to start by the generic dmabuf support in VFIO, as
it covers multiple use cases. Then, we can look at virtio-gpu.
Or, is it ok to have two dmabuf implementations: one that is internal to VFIO
and takes a VFIORegion as input like this one and another one that takes a
VFIODevice and iovec as input and can be invoked externally?
May be this approach can be revisited a bit ? I haven't looked yet.
Thanks,
C.
