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 0/2] virtio_gpu: add F_CREATE_GUEST_HANDLE and F_BLOB_CTX_ID_FIX
Date: Wed,  2 Sep 2026 23:14:34 -0300	[thread overview]
Message-ID: <20260903021442.423274-1-val@invisiblethingslab.com> (raw)

Hi,

I've been working on actually implementing the "lost" CREATE_GUEST_HANDLE
feature, previously half-implemented and removed in crosvm
(https://crrev.com/c/8064741), which allows the guest to tell the device
backend to create a shareable handle to a guest-only memory blob (using
facilities like udmabuf or gntdev-dmabuf) which can be e.g. sent over
to the Wayland compositor when using the cross-domain capset.

This allows for cross-domain Wayland passthrough to:

1) have a zero-copy fast path for wl_shm (software rendered buffers)
   thanks to udmabuf being able to wrap memfds from regular clients;
2) share buffers coming from a passed-through dGPU;
3) have an alternative way to share memory when host-only buffers
   cannot be mapped due to lack of a host_visible virtio SHM region,
   which might not be available in some setups (e.g. on Xen).

I have a working implementation with the zero-copy fast path:

Backend: https://github.com/magma-gpu/rutabaga_gfx/pull/81
       + https://github.com/libkrun/libkrun/pull/822
Guest: https://codeberg.org/drakulix/wl-cross-domain-proxy/pulls/24
Kernel: want to link here when posting to lkml :) temporarily:
        https://github.com/valpackett/linux-qclaptops/commits/guest-handle
Demo video: https://social.treehouse.systems/@valpackett/117149550756102167

This requires adding two new virtio-gpu feature flags:

Obviously the original CREATE_GUEST_HANDLE itself; but during implementation
it was discovered that we need to change the CREATE_BLOB cmd handling in a
backwards-incompatible way, to ensure that code changes on both sides are
an clean-up rather than a pile-up of odd spaghetti conditionals.

If you're wondering why the explicit indication from the guest must be used
rather than the backend "lazily" creating the handles based on usage:
it is better for the guest userspace to explicitly know which ways of
sharing memory are supported, so that one can be auto-negotiated.
(discussed in https://github.com/magma-gpu/rutabaga_gfx/issues/66)

v2: added F_BLOB_CTX_ID_FIX
v1 has been lost to the moderation queue, but if it gets approved:
https://lore.kernel.org/all/20260827092120.97295-1-val@invisiblethingslab.com/

Thanks,
~val

---

Val Packett (2):
  virtio-gpu: support requesting host handles for guest-only blob
    resources
  virtio-gpu: add flag to negotiate always passing ctx_id to
    RESOURCE_CREATE_BLOB

 device-types/gpu/description.tex | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

-- 
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 Val Packett [this message]
2026-09-03  2:14 ` [PATCH v2 1/2] virtio-gpu: support requesting host handles for guest-only blob resources Val Packett
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-1-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.