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 2/2] virtio-gpu: add flag to negotiate always passing ctx_id to RESOURCE_CREATE_BLOB
Date: Wed, 2 Sep 2026 23:14:36 -0300 [thread overview]
Message-ID: <20260903021442.423274-3-val@invisiblethingslab.com> (raw)
In-Reply-To: <20260903021442.423274-1-val@invisiblethingslab.com>
virtio-gpu device backends typically use ctx_id to route commands to
different modules that implement distinct context types, e.g.
virglrenderer vs. cross-domain. Each module may require the blob
resources intented to use with it to be allocated through it as well.
Currently, this happens for host-only and default blobs which are
allocated from a context-specific local blob_id (e.g. an image
requirements blob in cross-domain). For guest-only resources however,
existing software (both the Linux kernel and the rutabaga-gfx library
used by device backends to implement virtio-gpu) allocates those with
ctx_id == 0, which might be a different "default" context type from the
one the resource is intended to be used with, e.g. when both
virglrenderer and cross-domain are present, the socket buffers used by
cross-domain were processed by virglrenderer which happens to work
but does not actually make sense.
Additionally we would like to support PRIME imported resources (udmabufs
or dGPU passthrough dma-bufs) being passed over cross-domain with the
CREATE_GUEST_HANDLE feature, which due to API constraints must also
perform the creation of a guest-only blob resource with ctx_id but
without blob_id.
Unfortunately changing this without breaking backwards compatibility
requires a flag to negotiate the use of the "fixed" convention. Otherwise
new guest kernel + old rutabaga would result in the command failing due
to old rutabaga not expecting guest resources to be allocated w/ ctx_id.
Signed-off-by: Val Packett <val@invisiblethingslab.com>
---
device-types/gpu/description.tex | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/device-types/gpu/description.tex b/device-types/gpu/description.tex
index 64e8c4ddecc5..c0ff3f34ec1c 100644
--- a/device-types/gpu/description.tex
+++ b/device-types/gpu/description.tex
@@ -42,6 +42,9 @@ \subsection{Feature bits}\label{sec:Device Types / GPU Device / Feature bits}
\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.
+\item[VIRTIO_GPU_F_BLOB_CTX_ID_FIX (7)] it is always safe to pass the
+ current context ID to VIRTIO_GPU_CMD_RESOURCE_CREATE_BLOB,
+ including for guest-only blobs.
\end{description}
\subsection{Device configuration layout}\label{sec:Device Types / GPU Device / Device configuration layout}
@@ -673,6 +676,12 @@ \subsubsection{Device Operation: controlq}\label{sec:Device Types / GPU Device /
identified by the \field{blob_id}. The actual allocation is done via
VIRTIO_GPU_CMD_SUBMIT_3D.
+If VIRTIO_GPU_F_BLOB_CTX_ID_FIX has been negotiated, the \field{ctx_id} of
+the \field{hdr} MUST always be filled in with the ID of the default rendering
+context associated with the current handle, if one exists. Otherwise, it MUST
+only be filled when the \field{blob_id} has been filled to create a resource
+from a rendering context local object.
+
The driver MUST inform the device if the blob resource is used for
memory access, sharing between driver instances and/or sharing with
other devices. This is done via the \field{blob_flags} field.
--
2.55.0
next prev parent 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 ` [PATCH v2 1/2] virtio-gpu: support requesting host handles for guest-only blob resources Val Packett
2026-09-03 2:14 ` Val Packett [this message]
[not found] ` <CAAfnVBmzsXrOwEoaBWeUNCwrnh7bpZ_gtqSpakz6zaiANQrjhg@mail.gmail.com>
2026-09-04 0:19 ` [PATCH v2 2/2] virtio-gpu: add flag to negotiate always passing ctx_id to RESOURCE_CREATE_BLOB 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-3-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox