From: Vivek Kasireddy <vivek.kasireddy@intel.com>
To: qemu-devel@nongnu.org
Cc: "Vivek Kasireddy" <vivek.kasireddy@intel.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Akihiko Odaki" <odaki@rsg.ci.i.u-tokyo.ac.jp>,
"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
"Alex Williamson" <alex@shazbot.org>,
"Cédric Le Goater" <clg@redhat.com>,
"Leon Romanovsky" <leon@kernel.org>,
"Leon Romanovsky" <leonro@nvidia.com>,
"Jason Gunthorpe" <jgg@nvidia.com>,
"Dongwon Kim" <dongwon.kim@intel.com>
Subject: [PATCH v3 0/9] vfio: Implement VFIO_DEVICE_FEATURE_DMA_BUF and use it in virtio-gpu
Date: Fri, 21 Nov 2025 22:46:21 -0800 [thread overview]
Message-ID: <20251122064936.2948632-1-vivek.kasireddy@intel.com> (raw)
The virtio-gpu driver running in the Guest VM can create Guest blob
resources (by importing dmabufs) that are backed by System RAM. This
is made possible by making use of memfd memory backend and udmabuf
driver on the Host side. However, in order to create Guest blobs
that are backed by vfio-pci device regions (which happens when
virtio-gpu imports dmabufs from devices that have local memory such
as dGPU VFs), we have to implement VFIO_DEVICE_FEATURE_DMA_BUF and
leverage it in virtio-gpu.
So, while creating the blobs we use ram_block_is_memfd_backed() to
figure out if the blob is backed by memfd or a vfio-pci device. If
it is determined that the blob is backed by vfio-pci device region,
instead of calling into udmabuf driver to create a dmabuf fd we would
now call into vfio-pci driver to have a dmabuf fd created on the Host.
Changelog:
v2 -> v3:
- Use memory_region_get_ram_ptr() to obtain hva for both memfd and
VFIO backed memory regions (Akihiko)
- Drop the patch that introduced qemu_iovec_same_memory_regions()
helper and move the "same memory region" check into
virtio_gpu_create_udmabuf(), vfio_device_create_dmabuf_fd() (Akihiko)
- Refactor virtio_gpu_init_dmabuf() to not rely on helpers such as
memory_region_is_ram_device() to identify memory regions and
instead call virtio_gpu_create_udmabuf() unconditionally (Akihiko)
- Add a patch to introduce ram_block_is_memfd_backed() helper
v1 -> v2:
- Drop the patch that uses res->blob_size instead of res->blob to
identify blob resources (Akihiko)
- Remove the res->dmabuf_fd < 0 check while attaching backing to a
resource (Akihiko)
- Remove cmd->cmd_hdr.type != VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB
check while attaching backing (Akihiko)
- Improve vfio_get_region_index_from_mr() and add documentation (Cedric)
- Remove rcu_read_lock/unlock around qemu_ram_block_from_host()
(Akihiko, Cedric)
- Improve, document and rename vfio_device_create_dmabuf() to
vfio_device_create_dmabuf_fd() (Cedric)
- Add a new helper to lookup VFIO device from memory region (Cedric)
- Document vfio_device_get_region_info() (Cedric)
- Ensure that info variable (in vfio_dmabuf_mmap()) is initialized
before use (Cedric)
- Rename udmabuf files and helpers to dmabuf (Akihiko)
- Remove the redundant check for virtio_gpu_have_udmabuf() in
virtio_gpu_init_dmabuf() (Akihiko)
- Add a helper to check whether all the entries of a dmabuf belong
to a single memory region or not (Akihiko)
RFC -> v1:
- Create the CPU mapping using vfio device fd if the dmabuf exporter
(vfio-pci) does not provide mmap() support (Akihiko)
- Log a warning with LOG_GUEST_ERROR instead of warn_report() when
dmabuf cannot be created using Guest provided addresses (Akihiko)
- Use address_space_translate() instead of gpa2hva() to obtain the
Host addresses (Akihiko)
- Rearrange the patches and improve the commit messages (Akihiko)
- Fix compilation error when VFIO is not enabled (Alex)
- Add a new helper to obtain VFIO region index from memory region
- Move vfio_device_create_dmabuf() to hw/vfio/device.c
Tested with an SRIOV enabled Intel dGPU (B60) by running Gnome Wayland
(in the VM) and Qemu with the following (relevant) parameters:
-device vfio-pci,host=0000:03:00.1
-device virtio-vga,max_outputs=1,xres=1920,yres=1080,blob=true
-display gtk,gl=on
Associated vfio-pci kernel driver series:
https://lore.kernel.org/dri-devel/20251120-dmabuf-vfio-v9-0-d7f71607f371@nvidia.com/
Associated virtio-gpu kernel driver series (merged):
https://lore.kernel.org/dri-devel/20241126031643.3490496-1-vivek.kasireddy@intel.com/
---
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>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Leon Romanovsky <leonro@nvidia.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Dongwon Kim <dongwon.kim@intel.com>
Vivek Kasireddy (9):
virtio-gpu: Recreate the resource's dmabuf if new backing is attached
virtio-gpu: Find hva for Guest's DMA addr associated with a ram device
vfio: Document vfio_device_get_region_info()
vfio/region: Add a helper to get region index from memory region
vfio/device: Add a helper to lookup VFIODevice from memory region
vfio/device: Add support for VFIO_DEVICE_FEATURE_DMA_BUF
virtio-gpu: Rename udmabuf files and helpers to dmabuf
virtio-gpu-dmabuf: Introduce ram_block_is_memfd_backed() helper
virtio-gpu-dmabuf: Create dmabuf for blobs associated with VFIO
devices
hw/display/Kconfig | 5 +
hw/display/meson.build | 4 +-
...abuf-stubs.c => virtio-gpu-dmabuf-stubs.c} | 4 +-
...rtio-gpu-udmabuf.c => virtio-gpu-dmabuf.c} | 155 +++++++++++++++---
hw/display/virtio-gpu.c | 31 +++-
hw/vfio/device.c | 57 +++++++
hw/vfio/region.c | 14 ++
include/hw/vfio/vfio-device.h | 46 ++++++
include/hw/virtio/virtio-gpu.h | 6 +-
9 files changed, 288 insertions(+), 34 deletions(-)
rename hw/display/{virtio-gpu-udmabuf-stubs.c => virtio-gpu-dmabuf-stubs.c} (79%)
rename hw/display/{virtio-gpu-udmabuf.c => virtio-gpu-dmabuf.c} (58%)
--
2.50.1
next reply other threads:[~2025-11-22 7:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-22 6:46 Vivek Kasireddy [this message]
2025-11-22 6:46 ` [PATCH v3 1/9] virtio-gpu: Recreate the resource's dmabuf if new backing is attached Vivek Kasireddy
2025-11-22 6:46 ` [PATCH v3 2/9] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device Vivek Kasireddy
2025-11-22 6:46 ` [PATCH v3 3/9] vfio: Document vfio_device_get_region_info() Vivek Kasireddy
2025-11-22 6:46 ` [PATCH v3 4/9] vfio/region: Add a helper to get region index from memory region Vivek Kasireddy
2025-11-22 6:46 ` [PATCH v3 5/9] vfio/device: Add a helper to lookup VFIODevice " Vivek Kasireddy
2025-11-22 6:46 ` [PATCH v3 6/9] vfio/device: Add support for VFIO_DEVICE_FEATURE_DMA_BUF Vivek Kasireddy
2025-11-22 6:46 ` [PATCH v3 7/9] virtio-gpu: Rename udmabuf files and helpers to dmabuf Vivek Kasireddy
2025-11-22 6:46 ` [PATCH v3 8/9] virtio-gpu-dmabuf: Introduce ram_block_is_memfd_backed() helper Vivek Kasireddy
2025-11-22 6:46 ` [PATCH v3 9/9] virtio-gpu-dmabuf: Create dmabuf for blobs associated with VFIO devices Vivek Kasireddy
2025-11-22 7:25 ` Akihiko Odaki
2025-11-23 6:17 ` Kasireddy, Vivek
2025-11-23 8:36 ` Akihiko Odaki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251122064936.2948632-1-vivek.kasireddy@intel.com \
--to=vivek.kasireddy@intel.com \
--cc=alex.bennee@linaro.org \
--cc=alex@shazbot.org \
--cc=clg@redhat.com \
--cc=dmitry.osipenko@collabora.com \
--cc=dongwon.kim@intel.com \
--cc=jgg@nvidia.com \
--cc=leon@kernel.org \
--cc=leonro@nvidia.com \
--cc=marcandre.lureau@redhat.com \
--cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).