muvm-guest: pwbridge: forward fds on send#223
Merged
slp merged 1 commit intoAsahiLinux:mainfrom Apr 21, 2026
Merged
Conversation
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. |
WhatAmISupposedToPutHere
approved these changes
Apr 20, 2026
teohhanhui
requested changes
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. 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>
teohhanhui
approved these changes
Apr 20, 2026
Collaborator
|
Good stuff here, thanks @aford173 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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