From: Val Packett <val@invisiblethingslab.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>,
David Airlie <airlied@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Gurchetan Singh <gurchetansingh@chromium.org>,
Chia-I Wu <olvaffe@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Simona Vetter <simona@ffwll.ch>, Sergio Lopez <slp@redhat.com>
Cc: dri-devel@lists.freedesktop.org, virtualization@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] drm/virtio: do not enforce blob_alignment in cross-domain contexts
Date: Thu, 8 Oct 2026 17:59:51 -0300 [thread overview]
Message-ID: <4d86ec37-ce27-4556-966e-4b4e80ec0718@invisiblethingslab.com> (raw)
In-Reply-To: <8b0fbe1a-1410-42d7-8031-611795ae39d9@collabora.com>
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 <val@invisiblethingslab.com>
>> ---
>>
>> v2: also check has_virgl_3d to prevent dereferencing NULL vfpriv
>> v1: https://lore.kernel.org/all/20261006004044.2242154-1-val@invisiblethingslab.com/
>>
>> ~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.
~val
prev parent reply other threads:[~2026-10-08 20:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 15:42 Val Packett
2026-10-08 7:33 ` Dmitry Osipenko
2026-10-08 20:59 ` Val Packett [this message]
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=4d86ec37-ce27-4556-966e-4b4e80ec0718@invisiblethingslab.com \
--to=val@invisiblethingslab.com \
--cc=airlied@redhat.com \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=kraxel@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=olvaffe@gmail.com \
--cc=simona@ffwll.ch \
--cc=slp@redhat.com \
--cc=tzimmermann@suse.de \
--cc=virtualization@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
all inboxes | Powered by JetHome®