Re: [PATCH v2 2/2] virtio-gpu: add flag to negotiate always passing ctx_id to RESOURCE_CREATE_BLOB

[Val Packett <val@invisiblethingslab.com>]

On 9/3/26 7:20 PM, Gurchetan Singh wrote:
>
>
> On Wed, Sep 2, 2026 at 7:15 PM Val Packett 
> <val@invisiblethingslab.com> 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.
>
>
>
> I can confirm for gfxstream/rutabaga_gfx, it is robust enough to 
> handle ctx_id != 0 + BLOB_MEM for all versions we care about.
> [..]

Umm, as long as "versions we care about" means only current git main 
right now..??

Before the latest fixes (PR #81), this would not work for cross-domain, 
starting with its socket buffers.

With ctx_id != 0 rutabaga dispatches to the context's 
context_create_blob impl. For the guest memory (blob_id == 0) that would 
unconditionally try to get the 0th context item and fail with 
RutabagaError::InvalidCrossDomainItemId. Only component-level 
create_blob (used via ctx_id == 0) would handle guest memory.

The flag means "that won't happen anymore", so VMMs built with rutabaga 
 >0.1.85 can set it, in which case the guest will happily go through the 
(ctx_id != 0, blob_id == 0) code path.

~val