mirrors/crosvm
1
0
Fork 0
mirror of https://chromium.googlesource.com/crosvm/crosvm synced 2024-10-23 04:46:29 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
crosvm/vm_control/Cargo.toml

16 lines
382 B
TOML
Raw Normal View History

Move vm_control to a top-level crate Break out vm_control to a crate that will be able to used by more modules. Having vm_control usable from outside crosvm makes it possible to move the devices out of crosvm in a later commit. Change-Id: I1f060700ed49b5d77519d55efa2430490d521256 Signed-off-by: Dylan Reid <dgreid@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/706558 Reviewed-by: Zach Reizner <zachr@chromium.org>
2017-10-06 22:30:34 +00:00
[package]
name = "vm_control"
version = "0.1.0"
authors = ["The Chromium OS Authors"]
edition: Update vm_control to 2018 edition Separated out of CL:1513058 to make it possible to land parts individually while the affected crate has no other significant CLs pending. This avoids repeatedly introducing non-textual conflicts with new code that adds `use` statements. TEST=cargo check TEST=cargo check --all-features TEST=cargo check --target aarch64-unknown-linux-gnu Change-Id: Iedc030e90e4c4e11cf69dde711df24caafc0ea4c Reviewed-on: https://chromium-review.googlesource.com/1520074 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: David Tolnay <dtolnay@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: David Tolnay <dtolnay@chromium.org>
2019-03-13 04:05:08 +00:00
edition = "2018"
Move vm_control to a top-level crate Break out vm_control to a crate that will be able to used by more modules. Having vm_control usable from outside crosvm makes it possible to move the devices out of crosvm in a later commit. Change-Id: I1f060700ed49b5d77519d55efa2430490d521256 Signed-off-by: Dylan Reid <dgreid@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/706558 Reviewed-by: Zach Reizner <zachr@chromium.org>
2017-10-06 22:30:34 +00:00
[dependencies]
data_model = { path = "../data_model" }
Use hypervisor abstraction to run VMs Calls to the kvm crate have been replaced by calls to hypervisor and devices::irqchip. Plugin is unchanged and still KVM-specific. x86 creates and configures vcpus on the vcpu thread instead of the main thread. Code that still depends on kvm or kvm_sys: - crosvm_plugin, plugin, and protos use kvm and kvm_sys if built with the plugin feature - devices::VfioGroup does a kvm_sys ioctl - devices::irqchip and hypervisor use kvm_sys. hypervisor uses kvm::Cap and kvm::CpuId internally for now. BUG=chromium:1077058 TEST=runs es2gears_wayland on kukui TEST=runs evince on amd64-generic with kernel and split irqchip TEST=build_test excluding tpm2 TEST=cargo check --features plugin Change-Id: I0068e34da6a5ff0079b1237be1958933bf12ffe4 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2307711 Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Steven Richman <srichman@google.com>
2020-06-21 04:45:32 +00:00
hypervisor = { path = "../hypervisor" }
Move vm_control to a top-level crate Break out vm_control to a crate that will be able to used by more modules. Having vm_control usable from outside crosvm makes it possible to move the devices out of crosvm in a later commit. Change-Id: I1f060700ed49b5d77519d55efa2430490d521256 Signed-off-by: Dylan Reid <dgreid@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/706558 Reviewed-by: Zach Reizner <zachr@chromium.org>
2017-10-06 22:30:34 +00:00
libc = "*"
crosvm: use msg_socket in vm_control Refactor existing code to use msg_socket. BUG=None TEST=local build and run Change-Id: Iee72326b330e035303f679e1aedd6e5d18ad4f8a Reviewed-on: https://chromium-review.googlesource.com/1260260 Commit-Ready: Jingkui Wang <jkwang@google.com> Tested-by: Jingkui Wang <jkwang@google.com> Reviewed-by: Zach Reizner <zachr@chromium.org>
2018-10-03 20:04:47 +00:00
msg_socket = { path = "../msg_socket" }
cargo: Sort all dependency lists in Cargo.toml This may help reduce cases of conflicts between independent CLs each appending a dependency at the bottom of the list, of which I hit two today rebasing some of my open CLs. TEST=cargo check --all-features Change-Id: Ief10bb004cc7b44b107dc3841ce36c6b23632aed Reviewed-on: https://chromium-review.googlesource.com/1557172 Commit-Ready: David Tolnay <dtolnay@chromium.org> Tested-by: David Tolnay <dtolnay@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
2019-04-06 21:30:04 +00:00
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" }
Add "base" crate and transition crosvm usages to it from sys_util For now, this crate simply re-exports all of sys_util, but it will be updated to provide new interfaces when needed. This is the first step to making crosvm not directly depend on sys_util, so that we can make the interface changes we need without fear of negatively affecting (i.e. completely breaking) other usages within chromeos. BUG=b:162363783 TEST=./build_test Change-Id: I7d0aa3d8a1f66af1c7fee8fd649723ef17027150 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2325168 Tested-by: Michael Hoyle <mikehoyle@google.com> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Michael Hoyle <mikehoyle@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org>
2020-08-03 03:09:41 +00:00
base = { path = "../base" }
vm_memory: A crate to hold vm-specific memory objects Move GuestAddress and GuestMemory to a new crate for VM memory. This will make separating sys_util and crosvm independent making it easier to use sys_util functions outside of crosvm. Change-Id: I12e14948ea85754dfa6267b3a3fb32b77ef6796e Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2311251 Auto-Submit: Dylan Reid <dgreid@chromium.org> Commit-Queue: Dylan Reid <dgreid@chromium.org> Tested-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org>
2020-07-21 03:21:11 +00:00
vm_memory = { path = "../vm_memory" }
Reference in a new issue Copy permalink