crosvm/vm_control/Cargo.toml

15 lines
338 B
TOML
Raw Normal View History

[package]
name = "vm_control"
version = "0.1.0"
authors = ["The Chromium OS Authors"]
edition = "2018"
[dependencies]
data_model = { path = "../data_model" }
kvm = { path = "../kvm" }
libc = "*"
msg_socket = { path = "../msg_socket" }
resources = { path = "../resources" }
kvm: allow registering memory from current address space This is good for enabling non-exportable Vulkan host coherent memory, along with anything else where an exportable OS object isn't supported. This CL introduces: 1. ExternalMapping, which wraps an external library mapping using function callbacks, for purposes of sharing device memory to the guest in the case where the device memory is not compatible with the mmap interface. This is common in Vulkan when VkDeviceMemory is host visible but not external, or external but based on an opaque fd. The lifetime of the library mapping is tied to the lifetime of the ExternalMapping. 2. Usually, we would send such memory requests over a socket to the main thread. However, since these new objects require more metadata than other requests that are sent over the wire (because there's information about inheritance and refcounts), we also plumb the "map_request" field, which wraps a single ExternalMapping. Note that this ExternalMapping will not work in the sandbox case. In the sandbox case, we will then have to figure out how to serialize/deserialize ExternalMapping requests over a socket. BUG=b/146066070, b/153580313 TEST=compile and test Change-Id: I3b099b308aec45a313a8278ed6274f9dec66c30b Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034029 Tested-by: Gurchetan Singh <gurchetansingh@chromium.org> Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org>
2020-01-31 21:55:35 +00:00
sync = { path = "../sync" }
sys_util = { path = "../sys_util" }