Skip to content

muvm-guest: pwbridge: forward fds on send#223

Merged
slp merged 1 commit intoAsahiLinux:mainfrom
aford173:pipewire
Apr 21, 2026
Merged

muvm-guest: pwbridge: forward fds on send#223
slp merged 1 commit intoAsahiLinux:mainfrom
aford173:pipewire

Conversation

@aford173
Copy link
Copy Markdown

@aford173 aford173 commented Apr 20, 2026

Any outgoing Pipewire message with num_fd > 0 previously hit unimplemented!(), which in practice crashed the guest on the first ClientNode.PortBuffers that any pw-stream / pw-filter client emits.

Drain the expected fds from request_fds, convert each via vgpu_id_from_prime into a CrossDomainResource + GemHandleFinalizer, and attach them to the StreamSendResult. If request_fds is short of what the header claims, warn and return EIO instead of panicking.

Replace the unreachable!() PipeWireResourceFinalizer stub with an enum that dispatches to GemHandleFinalizer, so the finalizers produced here actually run.

Requires: containers/libkrun#644

@WhatAmISupposedToPutHere
Copy link
Copy Markdown
Member

Can you check which specific pipewire message is carrying those FDs? I do not want to unconditionally treat all fds as dma bufs, just in case there are things that need special handling.

Comment thread crates/muvm/src/guest/bridge/pipewire.rs Outdated
Comment thread crates/muvm/src/guest/bridge/pipewire.rs Outdated
Comment thread crates/muvm/src/guest/bridge/pipewire.rs Outdated
Comment thread crates/muvm/src/guest/bridge/pipewire.rs Outdated
Any outgoing Pipewire message with num_fd > 0 previously hit
unimplemented!(), which in practice crashed the guest on the first
ClientNode.PortBuffers that any pw-stream / pw-filter client emits.

Handle fd-bearing send messages by draining the expected fds from
request_fds, converting each via vgpu_id_from_prime into a
CrossDomainResource + GemHandleFinalizer, and attaching them to the
StreamSendResult. If request_fds is short of what the header claims,
warn and return EIO instead of panicking.

Only ClientNode.PortBuffers is treated as fd-bearing on the send path.
Per the PipeWire 1.6 native protocol that is the only client->server
method whose fds are dma-buf candidates — each fd corresponds to an
SPA_Data in the submitted buffer pool. SecurityContext.Create is the
only other send-side method that carries fds (a unix socket + an
eventfd, neither of which are dma-bufs); it is not supported by this
bridge. Any other fd-bearing send message — a future protocol
addition, an unsupported interface, or a malformed client — warns and
returns EIO rather than blindly handing the fd to
DRM_IOCTL_PRIME_FD_TO_HANDLE, which would EINVAL on anything that
isn't a dma-buf and yield an opaque failure.

Replace the unreachable!() PipeWireResourceFinalizer stub with an
enum that dispatches to GemHandleFinalizer, so the finalizers
produced here actually run.

Signed-off-by: Adam Ford <adam.ford@anodize.com>
@slp
Copy link
Copy Markdown
Collaborator

slp commented Apr 21, 2026

Good stuff here, thanks @aford173

@slp slp merged commit 56c6abc into AsahiLinux:main Apr 21, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants