Skip to content

Conversation

slp
Copy link
Collaborator

@slp slp commented Feb 19, 2024

No description provided.

@slp slp force-pushed the virtio-gpu-venus-v3 branch from 3447259 to 181d6e9 Compare February 20, 2024 12:34
@slp slp marked this pull request as ready for review February 20, 2024 12:40
slp added 7 commits February 20, 2024 17:21
Implement a wrapper for hv_vm_unmap, as we're going to need it in the
following commits.

Signed-off-by: Sergio Lopez <[email protected]>
Some devices require adding and removing mappings to a memory region
that's visible to the guest. On Linux, this can be done by simply adding
maps on top of a single map covering the whole shared region. But, on
macOS, for a new map to be visible on the guest, Hypervisor.framework
must be explictly notified via hv_vm_map/hv_vm_unmap.

This commit adds the required infrastructure for devices to request
HVF the addition and removal of mappings.

Signed-off-by: Sergio Lopez <[email protected]>
On macOS, the ability to share buffers using file descriptors is very
limited, specially for GPU buffers. To overcome this limitation, we need
to introduce a different way for sharing buffers that allows us to map
them once in virglrenderer, and inject that mapping as-is to the guest
using HVF.

Instead of breaking export_blob(), we introduce the function
get_map_ptr(), only available on macOS.

Signed-off-by: Sergio Lopez <[email protected]>
Make use of the recently introduced map/unmap request mechanism and the
get_map_ptr() extension in rutabaga to inject GPU buffers directly from
whatever MoltenVK/Metal has mapped them into our process space to the
guest.

Signed-off-by: Sergio Lopez <[email protected]>
Enable the RESOURCE_UUID feature as it's required by Venus.

Signed-off-by: Sergio Lopez <[email protected]>
Update Cargo.lock to accomodate latest changes in crates.

Signed-off-by: Sergio Lopez <[email protected]>
@slp slp force-pushed the virtio-gpu-venus-v3 branch from 277b020 to 498e405 Compare February 20, 2024 16:22
Use install_name_tool to rename the internal name (id) of the dylib to
ensure it's located properly when linking to it.

Signed-off-by: Sergio Lopez <[email protected]>
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.

1 participant