From: Demi Marie Obenour <demiobenour@gmail.com>
To: Val Packett <val@invisiblethingslab.com>, virtio-comment@lists.linux.dev
Cc: "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>
Subject: Re: [PATCH v2 2/2] virtio-gpu: add flag to negotiate always passing ctx_id to RESOURCE_CREATE_BLOB
Date: Fri, 4 Sep 2026 11:35:46 -0400 [thread overview]
Message-ID: <a5d79e14-0064-4941-9891-c71a9660cf5a@gmail.com> (raw)
In-Reply-To: <20260903021442.423274-3-val@invisiblethingslab.com>
[-- Attachment #1.1: Type: text/plain, Size: 3549 bytes --]
On 9/2/26 22:14, Val Packett wrote:
> 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.
Should VIRTIO_GPU_F_CREATE_GUEST_HANDLE require VIRTIO_GPU_F_BLOB_CTX_ID_FIX?
That could simplify drivers.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-09-04 15:36 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 ` [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 [this message]
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=a5d79e14-0064-4941-9891-c71a9660cf5a@gmail.com \
--to=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=val@invisiblethingslab.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