All of lore.kernel.org
 help / color / mirror / Atom feed
From: Val Packett <val@invisiblethingslab.com>
To: virtio-comment@lists.linux.dev
Cc: "Val Packett" <val@invisiblethingslab.com>,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Sergio Lopez" <slp@redhat.com>,
	"Parav Pandit" <parav@nvidia.com>,
	dmitry.osipenko@collabora.com, mst@redhat.com,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>,
	"Alyssa Ross" <hi@alyssa.is>,
	"Demi Marie Obenour" <demiobenour@gmail.com>
Subject: [PATCH v2 1/2] virtio-gpu: support requesting host handles for guest-only blob resources
Date: Wed,  2 Sep 2026 23:14:35 -0300	[thread overview]
Message-ID: <20260903021442.423274-2-val@invisiblethingslab.com> (raw)
In-Reply-To: <20260903021442.423274-1-val@invisiblethingslab.com>

So far, desktop integration over VIRTIO_GPU_CAPSET_CROSS_DOMAIN has
relied on host-only blob resources, which are always backed by a
shareable object on the host side (such as a memfd or a DMA-BUF).

However, to access such resources the guest needs to use the
VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB command which is currently only
available when a VIRTIO_GPU_SHM_ID_HOST_VISIBLE shared memory region
exists, which is not possible in all environments (e.g. the memory
sharing model of the Xen hypervisor does not make it possible).

Also, this necessarily introduces copying for software-rendered client
buffers. The Wayland protocol makes clients responsible for allocating
their SHM buffer pools, which are ordinary guest kernel shared temporary
file objects (memfds). The only way to bridge those and host-only buffers
is a copy on every content update.

Host-only resources with the HOST_VISIBLE region were picked as the
default solution because it's easy to implement with KVM. However with
the introduction of the udmabuf driver, it also became possible to create
shareable handles (namely DMA-BUFs) for specific subranges of various
memfd objects (which can be the backing objects for a KVM guest's RAM).
And on the Xen side, gntdev-dmabuf provides a similar operation for
Xen grant references. With these capabilities, it should be possible
to use guest-only blob resources as well!

The udmabuf driver can also be used in the guest to complete the Wayland
SHM zero-copy fast path. A memfd allocated by an ordinary client,
completely unaware of virtualization, can be turned into a DMA-BUF (as
long as some conditions hold) which can be imported into the virtio-gpu
device. This new flag, VIRTIO_GPU_BLOB_FLAG_CREATE_GUEST_HANDLE,
indicates to the host that the provided memory range entries should be
used to construct a corresponding DMA-BUF on the host side as well,
so that this resource can then be sent over to the host Wayland
compositor using the cross-domain context's send command.

Signed-off-by: Val Packett <val@invisiblethingslab.com>
---
 device-types/gpu/description.tex | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/device-types/gpu/description.tex b/device-types/gpu/description.tex
index ac3b427725f6..64e8c4ddecc5 100644
--- a/device-types/gpu/description.tex
+++ b/device-types/gpu/description.tex
@@ -39,6 +39,9 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
   synchronization timelines supported.  Requires VIRTIO_GPU_F_VIRGL.
 \item[VIRTIO_GPU_F_BLOB_ALIGNMENT (5)] configuration field
   \field{blob_alignment} is valid. Requires VIRTIO_GPU_F_RESOURCE_BLOB.
+\item[VIRTIO_GPU_F_CREATE_GUEST_HANDLE (6)] guest-only blob resources
+  may be created with the VIRTIO_GPU_BLOB_FLAG_CREATE_GUEST_HANDLE flag.
+  Requires VIRTIO_GPU_F_RESOURCE_BLOB.
 \end{description}
 
 \subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
@@ -621,9 +624,10 @@ \subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device /
 #define VIRTIO_GPU_BLOB_MEM_HOST3D            0x0002
 #define VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST      0x0003
 
-#define VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE     0x0001
-#define VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE    0x0002
-#define VIRTIO_GPU_BLOB_FLAG_USE_CROSS_DEVICE 0x0004
+#define VIRTIO_GPU_BLOB_FLAG_USE_MAPPABLE        0x0001
+#define VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE       0x0002
+#define VIRTIO_GPU_BLOB_FLAG_USE_CROSS_DEVICE    0x0004
+#define VIRTIO_GPU_BLOB_FLAG_CREATE_GUEST_HANDLE 0x0008
 
 struct virtio_gpu_resource_create_blob {
        struct virtio_gpu_ctrl_hdr hdr;
@@ -673,6 +677,12 @@ \subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device /
 memory access, sharing between driver instances and/or sharing with
 other devices. This is done via the \field{blob_flags} field.
 
+If VIRTIO_GPU_F_CREATE_GUEST_HANDLE has been negotiated, the
+VIRTIO_GPU_BLOB_FLAG_CREATE_GUEST_HANDLE flag may be used to request the
+creation of a shareable host kernel handle for a guest-only blob resource.
+Guest-only resources using this flag MAY be created from the rendering context
+local object identified by the \field{blob_id}.
+
 If VIRTIO_GPU_F_VIRGL is set, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D
 and VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update the
 resource. There is no restriction on the image/buffer view the driver
-- 
2.55.0


  reply	other threads:[~2026-09-03  2:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03  2:14 [PATCH v2 0/2] virtio_gpu: add F_CREATE_GUEST_HANDLE and F_BLOB_CTX_ID_FIX Val Packett
2026-09-03  2:14 ` Val Packett [this message]
2026-09-03  2:14 ` [PATCH v2 2/2] virtio-gpu: add flag to negotiate always passing ctx_id to RESOURCE_CREATE_BLOB Val Packett
     [not found]   ` <CAAfnVBmzsXrOwEoaBWeUNCwrnh7bpZ_gtqSpakz6zaiANQrjhg@mail.gmail.com>
2026-09-04  0:19     ` Val Packett
2026-09-04 15:35   ` Demi Marie Obenour
2026-09-04 20:17     ` Val Packett

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=20260903021442.423274-2-val@invisiblethingslab.com \
    --to=val@invisiblethingslab.com \
    --cc=demiobenour@gmail.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=gurchetansingh@chromium.org \
    --cc=hi@alyssa.is \
    --cc=marmarek@invisiblethingslab.com \
    --cc=mst@redhat.com \
    --cc=parav@nvidia.com \
    --cc=slp@redhat.com \
    --cc=virtio-comment@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.