On Wed, Oct 14, 2026 at 2:02 PM Dmitry Osipenko
<[email protected]> wrote:
>
> On 10/10/26 22:40, Dmitry Osipenko wrote:
> > On 10/8/26 23:59, Val Packett wrote:
> >>
> >> On 10/8/26 4:33 AM, Dmitry Osipenko wrote:
> >>> On 10/6/26 18:42, Val Packett wrote:
> >>>> VIRTIO_GPU_F_BLOB_ALIGNMENT is designed for GPU rendering context types,
> >>>> however VIRTIO_GPU_CAPSET_CROSS_DOMAIN is not one of those. Resources
> >>>> created under cross-domain contexts are arbitrary shared system memory
> >>>> files, which includes unusual things like Wayland keymaps received
> >>>> from the host compositor. Do not enforce alignment requirements there.
> >>>>
> >>>> Fixes: 47248e0d8264 ("drm/virtio: honor blob_alignment requirements")
> >>>> Signed-off-by: Val Packett <[email protected]>
> >>>> ---
> >>>>
> >>>> v2: also check has_virgl_3d to prevent dereferencing NULL vfpriv
> >>>> v1: https://lore.kernel.org/all/20261006004044.2242154-1-
> >>>> [email protected]/
> >>>>
> >>>> ~val
> >>>>
> >>>> ---
> >>>>   drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +++-
> >>>>   1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/
> >>>> drm/virtio/virtgpu_ioctl.c
> >>>> index 3ddd5481d6bc..4d5ae062834d 100644
> >>>> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> >>>> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> >>>> @@ -551,7 +551,9 @@ static int verify_blob(struct virtio_gpu_device
> >>>> *vgdev,
> >>>>       params->blob_flags = rc_blob->blob_flags;
> >>>>       params->blob_hints = rc_blob->blob_hints;
> >>>>   -    if (vgdev->has_blob_alignment &&
> >>>> +    if (vgdev->has_blob_alignment && vgdev->has_virgl_3d &&
> >>>> +        (vfpriv->context_init &
> >>>> VIRTIO_GPU_CONTEXT_INIT_CAPSET_ID_MASK) !=
> >>>> +        VIRTIO_GPU_CAPSET_CROSS_DOMAIN &&
> >>>>           !IS_ALIGNED(params->size, vgdev->blob_alignment))
> >>>>           return -EINVAL;
> >>>>
> >>> What userspace has this problem and why it re-purposes virtio-gpu to act
> >>> as udmabuf for arbitrary data that never reaches host?
> >>
> >> Sorry, what do you mean by that?
> >>
> >> This is not related to data that "never reaches host" at all! The error
> >> I referred to in the patch message literally says "received *from* the
> >> host"…??
> >>
> >> Guest userspace is any of the cross-domain proxies:
> >>
> >> * https://codeberg.org/drakulix/wl-cross-domain-proxy
> >> * https://github.com/talex5/wayland-proxy-virtwl
> >> * https://github.com/google/sommelier-rs (or old C++ version)
> >>
> >> VIRTIO_GPU_CAPSET_CROSS_DOMAIN "repurposes virtio-gpu" to act as a
> >> cross-VM UNIX socket transport that supports fd passing. By referring to
> >> virtio-gpu resources in the send command the guest can make the device
> >> send the resources' corresponding host fds to the host Wayland
> >> compositor. It can refer to resources from other contexts, in order to
> >> present drm/venus/etc rendered buffers on Wayland surfaces. (i.e. the
> >> host would send the actual dma-buf from virglrenderer) But the resources
> >> created on the cross-domain context itself are system memory buffers,
> >> generally used for software rendering and miscellaneous Wayland "stuff"
> >> like keymaps which are sent *from* the host, and exposed to Wayland
> >> clients in the guest. Socket receive handling in rutabaga-gfx stores
> >> incoming fds and returns their IDs to the guest, then the guest does a
> >> CREATE_BLOB with matching blob_id, which creates a virtio-gpu resource
> >> from the incoming buffer, so the guest can just MAP_BLOB it. These are
> >> the blobs that are not aligned to anything because they're just
> >> arbitrary memfds on the host.
> >
> > RE "These are the blobs that are not aligned to anything because they're
> > just arbitrary memfds on the host." I'll appreciate confirmation from
> > people more familiar with Sommelier internals like Gurchetan, Yiwei or Ryan.

Technically there's no need to enforce alignment on keymaps backed by
memfds, meanwhile those consumed by GPU have the proper alignment told
by CROSS_DOMAIN_CMD_GET_IMAGE_REQUIREMENTS (unless it fails to do the
right thing).

> >
> > In a case it is a correct claim, might be better to remove the
> > blob_alignment check entirely and let blob sharing fail naturally if
> > alignment is wrong.
> >
>
> Reproduced the bug with Sommelier.
>
> Driver always implicitly rounds up BO size up to PAGE_SIZE for both
> guest and host blobs [1][2], hence need to retain this old behavior to
> fix the problem properly.
>
> Please send v2
>
> [1]
> https://elixir.bootlin.com/linux/v7.2.10/source/drivers/gpu/drm/virtio/virtgpu_object.c#L217
> [2]
> https://elixir.bootlin.com/linux/v7.2.10/source/drivers/gpu/drm/virtio/virtgpu_vram.c#L210
>
> --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
> @@ -539,9 +539,15 @@ static int verify_blob(struct virtio_gpu_device *vgdev,
>         params->blob_flags = rc_blob->blob_flags;
>         params->blob_hints = rc_blob->blob_hints;
>
> -       if (vgdev->has_blob_alignment &&
> -           !IS_ALIGNED(params->size, vgdev->blob_alignment))
> -               return -EINVAL;
> +       /*
> +        * Blob sizes always implicitly rounded up to PAGE_SIZE by the
> +        * driver, userspace may be unaware of the host's alignment.
> +        * Round up to the larger of the host and guest page sizes.
> +        */
> +       if (vgdev->has_blob_alignment)
> +               params->size = ALIGN(params->size,
> +                                    max_t(u32, vgdev->blob_alignment,
> PAGE_SIZE));
>
>         return 0;
>  }
>
>
>
> --
> Best regards,
> Dmitry

I like Dmitry's latest proposal much better. Keeping the alignment
agnostic to the guest userspace is more seamless, which also covers
the implicit 4k alignment case without forcing userspace to adapt.

Best,
Yiwei

Reply via email to