In addition to memfd, a blob resource can also have its backing
storage in a VFIO device region. Since, there is no effective way
to determine where the backing storage is located, we first try to
create a dmabuf assuming it is in memfd. If that fails, we try to
create a dmabuf assuming it is in VFIO device region.
So, we first call virtio_gpu_create_udmabuf() to check if the blob's
backing storage is located in a memfd or not. If it is not, we invoke
the vfio_device_create_dmabuf_fd() API which identifies the right
VFIO device and eventually creates a dmabuf fd.
Note that, for mmapping the dmabuf, we directly call mmap() if the
dmabuf fd was created via virtio_gpu_create_udmabuf() since we know
that the udmabuf driver supports mmap(). However, if the dmabuf was
created via vfio_device_create_dmabuf_fd(), we use the
vfio_device_mmap_dmabuf() API to get a mapping for the dmabuf.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Alex Bennée <alex.bennee@linaro.org>
Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc: Alex Williamson <alex@shazbot.org>
Cc: Cédric Le Goater <clg@redhat.com>
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
---
hw/display/virtio-gpu-dmabuf.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/hw/display/virtio-gpu-dmabuf.c b/hw/display/virtio-gpu-dmabuf.c
index eddf398a43..ccb9c82a6f 100644
--- a/hw/display/virtio-gpu-dmabuf.c
+++ b/hw/display/virtio-gpu-dmabuf.c
@@ -147,9 +147,25 @@ void virtio_gpu_init_dmabuf(struct virtio_gpu_simple_resource *res)
if (res->dmabuf_fd == VFIO_DMABUF_CREATE_ERR_INVALID_IOV) {
error_free_or_abort(&local_err);
- qemu_log_mask(LOG_GUEST_ERROR,
- "Cannot create dmabuf: incompatible memory\n");
- return;
+ res->dmabuf_fd = vfio_device_create_dmabuf_fd(res->iov,
+ res->iov_cnt,
+ &local_err);
+ if (res->dmabuf_fd == VFIO_DMABUF_CREATE_ERR_INVALID_IOV) {
+ error_free_or_abort(&local_err);
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "Cannot create dmabuf: incompatible memory\n");
+ return;
+ }
+
+ if (res->dmabuf_fd >= 0) {
+ pdata = vfio_device_mmap_dmabuf(res->iov, res->iov_cnt,
+ res->blob_size, &local_err);
+ if (!pdata) {
+ virtio_gpu_destroy_dmabuf(res);
+ }
+ } else {
+ res->dmabuf_fd = -1;
+ }
} else if (res->dmabuf_fd >= 0) {
pdata = virtio_gpu_remap_dmabuf(res, &local_err);
if (!pdata) {
--
2.53.0
On 2026/03/11 11:50, Vivek Kasireddy wrote: > In addition to memfd, a blob resource can also have its backing > storage in a VFIO device region. Since, there is no effective way > to determine where the backing storage is located, we first try to > create a dmabuf assuming it is in memfd. If that fails, we try to > create a dmabuf assuming it is in VFIO device region. > > So, we first call virtio_gpu_create_udmabuf() to check if the blob's > backing storage is located in a memfd or not. If it is not, we invoke > the vfio_device_create_dmabuf_fd() API which identifies the right > VFIO device and eventually creates a dmabuf fd. > > Note that, for mmapping the dmabuf, we directly call mmap() if the > dmabuf fd was created via virtio_gpu_create_udmabuf() since we know > that the udmabuf driver supports mmap(). However, if the dmabuf was > created via vfio_device_create_dmabuf_fd(), we use the > vfio_device_mmap_dmabuf() API to get a mapping for the dmabuf. > > Cc: Marc-André Lureau <marcandre.lureau@redhat.com> > Cc: Alex Bennée <alex.bennee@linaro.org> > Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Cc: Alex Williamson <alex@shazbot.org> > Cc: Cédric Le Goater <clg@redhat.com> > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Now I think this patch implements proper handling of all error conditions and conforms the convention. Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
Hi Akihiko, > Subject: Re: [PATCH v11 10/10] virtio-gpu-dmabuf: Create dmabuf for > blobs associated with VFIO devices > > On 2026/03/11 11:50, Vivek Kasireddy wrote: > > In addition to memfd, a blob resource can also have its backing > > storage in a VFIO device region. Since, there is no effective way > > to determine where the backing storage is located, we first try to > > create a dmabuf assuming it is in memfd. If that fails, we try to > > create a dmabuf assuming it is in VFIO device region. > > > > So, we first call virtio_gpu_create_udmabuf() to check if the blob's > > backing storage is located in a memfd or not. If it is not, we invoke > > the vfio_device_create_dmabuf_fd() API which identifies the right > > VFIO device and eventually creates a dmabuf fd. > > > > Note that, for mmapping the dmabuf, we directly call mmap() if the > > dmabuf fd was created via virtio_gpu_create_udmabuf() since we know > > that the udmabuf driver supports mmap(). However, if the dmabuf was > > created via vfio_device_create_dmabuf_fd(), we use the > > vfio_device_mmap_dmabuf() API to get a mapping for the dmabuf. > > > > Cc: Marc-André Lureau <marcandre.lureau@redhat.com> > > Cc: Alex Bennée <alex.bennee@linaro.org> > > Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > Cc: Alex Williamson <alex@shazbot.org> > > Cc: Cédric Le Goater <clg@redhat.com> > > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> > > Now I think this patch implements proper handling of all error > conditions and conforms the convention. > > Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Thank you for taking the time to review these patches! Thanks, Vivek
Hi Cedric, > Subject: RE: [PATCH v11 10/10] virtio-gpu-dmabuf: Create dmabuf for > blobs associated with VFIO devices > > > > On 2026/03/11 11:50, Vivek Kasireddy wrote: > > > In addition to memfd, a blob resource can also have its backing > > > storage in a VFIO device region. Since, there is no effective way to > > > determine where the backing storage is located, we first try to > > > create a dmabuf assuming it is in memfd. If that fails, we try to > > > create a dmabuf assuming it is in VFIO device region. > > > > > > So, we first call virtio_gpu_create_udmabuf() to check if the blob's > > > backing storage is located in a memfd or not. If it is not, we > > > invoke the vfio_device_create_dmabuf_fd() API which identifies the > > > right VFIO device and eventually creates a dmabuf fd. > > > > > > Note that, for mmapping the dmabuf, we directly call mmap() if the > > > dmabuf fd was created via virtio_gpu_create_udmabuf() since we > know > > > that the udmabuf driver supports mmap(). However, if the dmabuf > was > > > created via vfio_device_create_dmabuf_fd(), we use the > > > vfio_device_mmap_dmabuf() API to get a mapping for the dmabuf. > > > > > > Cc: Marc-André Lureau <marcandre.lureau@redhat.com> > > > Cc: Alex Bennée <alex.bennee@linaro.org> > > > Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> > > > Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > > > Cc: Alex Williamson <alex@shazbot.org> > > > Cc: Cédric Le Goater <clg@redhat.com> > > > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> > > > > Now I think this patch implements proper handling of all error > > conditions and conforms the convention. > > > > Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> > Thank you for taking the time to review these patches! Can this series be merged to vfio-next given the dependencies on the newly added VFIO APIs? Thanks, Vivek
Hello Vivek, On 3/17/26 06:42, Kasireddy, Vivek wrote: > Hi Cedric, > >> Subject: RE: [PATCH v11 10/10] virtio-gpu-dmabuf: Create dmabuf for >> blobs associated with VFIO devices >>> >>> On 2026/03/11 11:50, Vivek Kasireddy wrote: >>>> In addition to memfd, a blob resource can also have its backing >>>> storage in a VFIO device region. Since, there is no effective way to >>>> determine where the backing storage is located, we first try to >>>> create a dmabuf assuming it is in memfd. If that fails, we try to >>>> create a dmabuf assuming it is in VFIO device region. >>>> >>>> So, we first call virtio_gpu_create_udmabuf() to check if the blob's >>>> backing storage is located in a memfd or not. If it is not, we >>>> invoke the vfio_device_create_dmabuf_fd() API which identifies the >>>> right VFIO device and eventually creates a dmabuf fd. >>>> >>>> Note that, for mmapping the dmabuf, we directly call mmap() if the >>>> dmabuf fd was created via virtio_gpu_create_udmabuf() since we >> know >>>> that the udmabuf driver supports mmap(). However, if the dmabuf >> was >>>> created via vfio_device_create_dmabuf_fd(), we use the >>>> vfio_device_mmap_dmabuf() API to get a mapping for the dmabuf. >>>> >>>> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> >>>> Cc: Alex Bennée <alex.bennee@linaro.org> >>>> Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> >>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> >>>> Cc: Alex Williamson <alex@shazbot.org> >>>> Cc: Cédric Le Goater <clg@redhat.com> >>>> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> >>> >>> Now I think this patch implements proper handling of all error >>> conditions and conforms the convention. >>> >>> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> >> Thank you for taking the time to review these patches! > Can this series be merged to vfio-next given the dependencies on > the newly added VFIO APIs? I could merge in advance the VFIO changes but the series does not apply nor compiles. We need feedback from the virtio-gpu maintainers that this proposal is a useful feature too. Since this is QEMU 11.1 material, we have some time. Let me review it first. Thanks, C.
Hi Cedric, > Subject: Re: [PATCH v11 10/10] virtio-gpu-dmabuf: Create dmabuf for > blobs associated with VFIO devices > > Hello Vivek, > > > >>> > >>> On 2026/03/11 11:50, Vivek Kasireddy wrote: > >>>> In addition to memfd, a blob resource can also have its backing > >>>> storage in a VFIO device region. Since, there is no effective way to > >>>> determine where the backing storage is located, we first try to > >>>> create a dmabuf assuming it is in memfd. If that fails, we try to > >>>> create a dmabuf assuming it is in VFIO device region. > >>>> > >>>> So, we first call virtio_gpu_create_udmabuf() to check if the blob's > >>>> backing storage is located in a memfd or not. If it is not, we > >>>> invoke the vfio_device_create_dmabuf_fd() API which identifies > the > >>>> right VFIO device and eventually creates a dmabuf fd. > >>>> > >>>> Note that, for mmapping the dmabuf, we directly call mmap() if > the > >>>> dmabuf fd was created via virtio_gpu_create_udmabuf() since we > >> know > >>>> that the udmabuf driver supports mmap(). However, if the dmabuf > >> was > >>>> created via vfio_device_create_dmabuf_fd(), we use the > >>>> vfio_device_mmap_dmabuf() API to get a mapping for the dmabuf. > >>>> > >>>> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> > >>>> Cc: Alex Bennée <alex.bennee@linaro.org> > >>>> Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> > >>>> Cc: Dmitry Osipenko <dmitry.osipenko@collabora.com> > >>>> Cc: Alex Williamson <alex@shazbot.org> > >>>> Cc: Cédric Le Goater <clg@redhat.com> > >>>> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> > >>> > >>> Now I think this patch implements proper handling of all error > >>> conditions and conforms the convention. > >>> > >>> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> > >> Thank you for taking the time to review these patches! > > Can this series be merged to vfio-next given the dependencies on > > the newly added VFIO APIs? > I could merge in advance the VFIO changes but the series does not > apply nor compiles. The current series is based on vfio-next. I'll rebase it on top of Qemu master for the next version. > We need feedback from the virtio-gpu maintainers > that this proposal is a useful feature too. All the virtio-gpu patches are thoroughly reviewed by Akihiko (who is a virtio-gpu reviewer). > > Since this is QEMU 11.1 material, we have some time. Let me review > it first. Ok, sounds good. Thanks, Vivek > > Thanks, > > C.
© 2016 - 2026 Red Hat, Inc.