2017-10-06 22:30:34 +00:00
|
|
|
[package]
|
|
|
|
|
name = "vm_control"
|
|
|
|
|
version = "0.1.0"
|
|
|
|
|
authors = ["The Chromium OS Authors"]
|
2019-03-13 04:05:08 +00:00
|
|
|
edition = "2018"
|
2017-10-06 22:30:34 +00:00
|
|
|
|
2020-10-21 06:57:33 +00:00
|
|
|
[features]
|
2021-08-04 18:44:49 +00:00
|
|
|
gdb = ["gdbstub_arch"]
|
2020-10-21 06:57:33 +00:00
|
|
|
|
2017-10-06 22:30:34 +00:00
|
|
|
[dependencies]
|
2021-01-07 16:30:28 +00:00
|
|
|
base = { path = "../base" }
|
2017-10-06 22:30:34 +00:00
|
|
|
data_model = { path = "../data_model" }
|
2021-08-04 18:44:49 +00:00
|
|
|
gdbstub_arch = { version = "0.1.0", optional = true }
|
2020-06-21 04:45:32 +00:00
|
|
|
hypervisor = { path = "../hypervisor" }
|
2017-10-06 22:30:34 +00:00
|
|
|
libc = "*"
|
2021-08-18 21:25:27 +00:00
|
|
|
remain = "*"
|
2019-04-06 21:30:04 +00:00
|
|
|
resources = { path = "../resources" }
|
rutabaga_gfx: rutabaga_gralloc: a shimmering beacon of hope
rutabaga_gralloc is a cross-platform, Rust-based buffer
manager.
The rationale for this change is:
1) For the {cross-domain, wayland} context type, we need to
have a good story for the crucial "wl-dmabuf" feature. As
minigbm has been thoroughly tested on ChromeOS and currently
powers the "wl-dmabuf" feature, it only makes sense for us to
have a path to minigbm for the cross-domain prototype. This
will be used by Sommelier.
2) While minigbm allocation works well on Chromebooks, it is
not sufficient for cross-platform purposes. For their Virtual
Graphics Interface (VGI) initiative, Android graphics
virtualization experts have expressed their desire for a Vulkan
based allocator. This will to go alongside cros_gralloc in
minigbm, which is considered by many to be the ""world's
premiere gralloc implementation".
3) Android graphics virtualization experts have expressed their
desire for vkMapMemory(..) to be used when crosvm is in
multi-process mode. Currently, only dma-buf mmap() is supported
for zero-copy blobs in multi-process mode. dma-buf mmap() is not
guaranteed to work on Nvidia (a "must have" for Cuttlefish) or
any other driver for that matter (we *make* it work for ChromeOS).
Possibly only solution: vkMapMemory ;-)
With these goals in mind, here's a summary of the revelant changes:
* Renamed the {gpu_allocator.rs, GpuMemoryAllocator trait} to be
{gralloc.rs, Gralloc trait}.
* Moved all GPU allocation out of the resources crate and into
the rutabaga_gfx crate. This will allow the resources crate to
be focused on managing resources for virtual machines.
* Moved the gpu_buffer crate into the gralloc module in the
rutabaga_gfx crate. The same functionality is now under
"minigbm.rs", "minigbm_bindings.rs" and "rendernode.rs"
* Added an optional dependency on vulkano.rs. vulkano.rs is a safe
Rust wrapper around the Vulkan api [a]. It's emphasis on type
safety makes a good fit for crosvm, though there are other high
quality crates out there (gfx-rs, ash.rs). Though development
has slowed down, it should satisfy goals (2) and (3) quite easily.
* Added a system_gralloc implementation based on memfd. This can be
used when minigbm or Vulkano features are not used, to replicate the
highly useful "wl-shm" feature in Sommelier. Astute observers will
note this can also enable seamless Wayland windowing without GPU
features for Android too. Some minor changes to the base crate were
needed.
* Cut down on the amount of DrmFormats to the subset needed by
Sommelier and cros_gralloc.
* Moved checked arithmetic into it's own file.
* Internally renamed to "wl-dmabuf" feature to be the "minigbm"
feature. This is because "wl-dmabuf" has a dependency on minigbm.
* Small rutabaga_gfx cleanups
[a] https://github.com/vulkano-rs/vulkano/blob/master/DESIGN.md
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=run sommelier with "wl-dmabuf" and "wl-shm"
Change-Id: I693a39cef64cd98e56d843d3c60caa7983d4d6e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626487
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
2020-12-09 18:44:13 +00:00
|
|
|
rutabaga_gfx = { path = "../rutabaga_gfx"}
|
2021-01-07 16:30:28 +00:00
|
|
|
serde = { version = "1", features = [ "derive" ] }
|
2021-05-24 08:13:45 +00:00
|
|
|
serde_json = "*"
|
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" }
|
2021-08-18 21:25:27 +00:00
|
|
|
thiserror = "*"
|
2020-07-21 03:21:11 +00:00
|
|
|
vm_memory = { path = "../vm_memory" }
|
