X11 cross-domain prep work #231
Merged
Conversation
This file contains 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
asahilina
force-pushed
the
x11-prep-work
branch
2 times, most recently
from
cf8a3f5 to
69f6509
Compare
|
For the first commit, note that the original code is also arguably buggy in that it's not handling the fence properly in the EOF case (it should requeue a |
asahilina
force-pushed
the
x11-prep-work
branch
from
69f6509 to
0cfb95b
Compare
asahilina
force-pushed
the
x11-prep-work
branch
4 times, most recently
from
f211305 to
4e165c6
Compare
asahilina
force-pushed
the
x11-prep-work
branch
4 times, most recently
from
228533d to
8824c01
Compare
There is no message type for the host closing a channel. This is reported by recvmsg as a 0-length result, as is typical UNIX EOF convention. So, just remove the guard so that we always report a 0-length message to the guest in this case, which can then interpret it as an orderly shutdown. Signed-off-by: Asahi Lina <[email protected]>
In order to support fence passing for the X11 protocol, we need to be able to share an opened fd (to a /dev/shm file opened with DAX) between the guest and the host. To do this, introduce a new ioctl() operation on the filesystem, which tags the handle as exported and inserts it into a shared table that can be shared with other subsystems. Semantics: - Shared FDs are required to be kept open by the guest until the host code uses the share. Closing the fd will remove the share (this ensures fds/shared don't leak if a share is unused). - Shares are identified by a filesystem ID and a handle ID, both u64. They are opaque as far as the user is concerned. Filesystem IDs are arbitrarily assigned at creation time from a static incrementing atomic counter. - There is no particular permissions/privilege checking for this mechanism. In other words, once an FD is exported, it can be used in any context where exported FDs are expected by handle (which is predictable and not secure), with no regard to permissions or privilege. It is expected that this mechanism will be used with a single-privilege-domain VM scenario. Only Linux is supported at this time (macOS only has stub support for the fields, no implemetation). Signed-off-by: Asahi Lina <[email protected]>
To support fence passing for the X11 protocol, add support for plumbing through the export_table shared with the virtiofs code into cross_domain. This is unused at this point. Signed-off-by: Asahi Lina <[email protected]>
Right now, this is done unconditionally for all filesystems. Should we introduce a flag for this? Signed-off-by: Asahi Lina <[email protected]>
Instead of trying to encode persistence in the LSB of the blob ID, just look at the actual type to do the right thing. Signed-off-by: Asahi Lina <[email protected]>
Not everything is a Wayland keymap. This is required for X11 to work. Signed-off-by: Asahi Lina <[email protected]>
slp
approved these changes
Oct 30, 2024
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.
Prep work for the X11 channel type that does not strictly implement the code. This will be a dependency of #213.
Most of this is implementing support for sharing file handles between the FS code and the GPU code, to implement fence passing. Please let me know if this approach looks sensible.