On 10/12/26 08:27, Kasireddy, Vivek wrote:
Hi Akihiko,
Subject: Re: [PATCH v13 6/9] vfio/device: Add support for creating dmabuf
from multiple ranges
In order to create a dmabuf associated with a buffer that spans
multiple ranges, we first need to identify the VFIO region and
index the buffer (represented by iovec) belongs to and then
translate its addresses to offsets within that region.
The qemu_ram_block_from_host() API gives us both the region and
the offset info we need to populate the dma ranges so that we can
invoke the VFIO_DEVICE_FEATURE_DMA_BUF feature to create the
dmabuf.
Also, instead of iterating over all QOM devices to find the
VFIODevice associated with a memory region, introduce a helper
to just use the vfio_device_list to lookup the VFIODevice.
And, introduce another helper to lookup the VFIO region given an
address.
Lastly, introduce an enum to return the type of error encountered
while creating the dmabuf fd.
Cc: Alex Williamson <[email protected]>
Cc: Cédric Le Goater <[email protected]>
Signed-off-by: Vivek Kasireddy <[email protected]>
---
include/hw/vfio/vfio-device.h | 22 +++++++
hw/vfio/device.c | 109 ++++++++++++++++++++++++++++++++++
hw/vfio/dmabuf-stubs.c | 17 ++++++
hw/vfio/meson.build | 1 +
4 files changed, 149 insertions(+)
create mode 100644 hw/vfio/dmabuf-stubs.c
diff --git a/include/hw/vfio/vfio-device.h b/include/hw/vfio/vfio-
device.h
index 8472420d3f..c05430be8a 100644
--- a/include/hw/vfio/vfio-device.h
+++ b/include/hw/vfio/vfio-device.h
@@ -41,6 +41,13 @@ enum {
VFIO_DEVICE_TYPE_AP = 3,
};
+enum {
+ /* The Guest passed addresses stored in IOV are invalid */
+ VFIO_DMABUF_CREATE_ERR_INVALID_IOV = -1,
+ /* Guest or Host may be at fault for this type of error */
+ VFIO_DMABUF_CREATE_ERR_UNSPEC = -2,
+};
Nack.
As said a few times already : it's a VFIO-specific enum leaking
into vfio-device.h to serve virtio-gpu's fallback logic. The
cleanest alternative is to use standard -errno returns and
make the fd an output parameter.
It looks like Cedric remains unconvinced about the value or usefulness
of this error enum. Therefore, to make progress, I intend to adopt his
suggestion to use standard -errno returns for the next version, considering
that this series has been stuck for a year.
Well, v12 was sent in March and v13 in October; that's a 7-month gap.
If you want to make progress on a series, sending updates more than
twice a year helps a lot. Maintainers context-switch between many
series; long gaps mean re-reading everything from scratch each time.
That said, converging on standard -errno is the right pattern IMO.
Widening the fallback trigger to also cover -ENODEV would be a
nice improvement for v14.
Thanks,
C.
