public inbox for qemu-devel@nongnu.org
 help / color / mirror / Atom feed
From: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
To: Vivek Kasireddy <vivek.kasireddy@intel.com>, qemu-devel@nongnu.org
Cc: "Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	"Alex Williamson" <alex@shazbot.org>,
	"Cédric Le Goater" <clg@redhat.com>
Subject: Re: [PATCH v12 10/10] virtio-gpu-dmabuf: Create dmabuf for blobs associated with VFIO devices
Date: Tue, 24 Mar 2026 18:11:31 +0900	[thread overview]
Message-ID: <6af4e73c-4ad5-4684-9982-04276b6b7daa@rsg.ci.i.u-tokyo.ac.jp> (raw)
In-Reply-To: <20260319052023.2088685-11-vivek.kasireddy@intel.com>

On 2026/03/19 14:15, 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>
> Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
> ---
>   hw/display/virtio-gpu-dmabuf.c | 23 ++++++++++++++++++++---
>   1 file changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git a/hw/display/virtio-gpu-dmabuf.c b/hw/display/virtio-gpu-dmabuf.c
> index 89aa487654..f953db0fbe 100644
> --- a/hw/display/virtio-gpu-dmabuf.c
> +++ b/hw/display/virtio-gpu-dmabuf.c
> @@ -147,9 +147,26 @@ 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,
> +                                                          res->blob_size,

The correspondence between (iov, iov_cnt) and blob_size is more of a 
internal concern of virtio-gpu, not of VFIO. This parameter is better 
removed from vfio_device_create_dmabuf_fd() and vfio_device_mmap_dmabuf().

Regards,
Akihiko Odaki

> +                                                          &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) {



  reply	other threads:[~2026-03-24  9:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19  5:15 [PATCH v12 00/10] vfio: Create dmabuf from multiple VFIO ranges and use it in virtio-gpu Vivek Kasireddy
2026-03-19  5:15 ` [PATCH v12 01/10] virtio-gpu: Recreate the resource's dmabuf if new backing is attached Vivek Kasireddy
2026-03-19  5:15 ` [PATCH v12 02/10] virtio-gpu: Find hva for Guest's DMA addr associated with a ram device Vivek Kasireddy
2026-03-19  5:15 ` [PATCH v12 03/10] virtio-gpu: Rename udmabuf files and helpers to dmabuf Vivek Kasireddy
2026-03-19  5:15 ` [PATCH v12 04/10] virtio-gpu-dmabuf: Remove rcu_read_lock/unlock from virtio_gpu_create_udmabuf() Vivek Kasireddy
2026-03-19  5:15 ` [PATCH v12 05/10] virtio-gpu-dmabuf: Use g_autofree for the list pointer Vivek Kasireddy
2026-03-19  5:15 ` [PATCH v12 06/10] vfio/region: Add a helper to get VFIO region from memory region Vivek Kasireddy
2026-03-23 17:38   ` Cédric Le Goater
2026-03-24  5:47     ` Kasireddy, Vivek
2026-03-19  5:15 ` [PATCH v12 07/10] vfio/device: Add support for creating dmabuf from multiple ranges Vivek Kasireddy
2026-03-23 18:02   ` Cédric Le Goater
2026-03-24  5:47     ` Kasireddy, Vivek
2026-03-19  5:15 ` [PATCH v12 08/10] vfio/device: Add a helper to mmap a dmabuf Vivek Kasireddy
2026-03-19  5:15 ` [PATCH v12 09/10] virtio-gpu-dmabuf: Improve error handling with 'Error **' and err enum Vivek Kasireddy
2026-03-23 17:51   ` Cédric Le Goater
2026-03-24  5:53     ` Kasireddy, Vivek
2026-03-24  8:58       ` Akihiko Odaki
2026-03-25  5:31         ` Kasireddy, Vivek
2026-03-25  8:27           ` Akihiko Odaki
2026-03-26  5:54             ` Kasireddy, Vivek
2026-03-19  5:15 ` [PATCH v12 10/10] virtio-gpu-dmabuf: Create dmabuf for blobs associated with VFIO devices Vivek Kasireddy
2026-03-24  9:11   ` Akihiko Odaki [this message]
2026-03-25  5:29     ` Kasireddy, Vivek
2026-03-25  8:02       ` Akihiko Odaki
2026-03-26  5:52         ` Kasireddy, Vivek
2026-03-26  6:15           ` 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=6af4e73c-4ad5-4684-9982-04276b6b7daa@rsg.ci.i.u-tokyo.ac.jp \
    --to=odaki@rsg.ci.i.u-tokyo.ac.jp \
    --cc=alex.bennee@linaro.org \
    --cc=alex@shazbot.org \
    --cc=clg@redhat.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vivek.kasireddy@intel.com \
    /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