mirrors/crosvm
1
0
Fork 0
mirror of https://chromium.googlesource.com/crosvm/crosvm synced 2024-11-25 05:03:05 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
crosvm/x86_64/Cargo.toml

25 lines
574 B
TOML
Raw Normal View History

x86_64: Add x86_64 setup code Change-Id: Ibdf83f8efcc92bf1f45ed9a5f95117fd9ae3ad5a Reviewed-on: https://chromium-review.googlesource.com/483868 Commit-Ready: Dylan Reid <dgreid@chromium.org> Tested-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org>
2017-04-21 00:33:17 +00:00
[package]
name = "x86_64"
version = "0.1.0"
authors = ["The Chromium OS Authors"]
x86_64: fill cache info in cpuid, stop spoofing CPU vendor id The fix passes through cache-related CPU entries 2, 4, 0x80000005 and 0x80000006 similar to how QEMU does it. Note passing this cpuid info itself is not sufficient unless CPU vendor is something Linux kernel recognizes. Therefore, I am removing cute spoofing of the vendor id, allowing host value to pass through. I believe it is generally a bad idea to spoof vendor id as lots of kernel and user space code gets confused and may take unoptimized paths. The corollary is that removing the spoofing may have unintended consequences correctness- and performance-wise. I would appreciate recommendation on additional testing. BUG=chromium:859678 TEST=lscpu in Guest, 'cargo test' Change-Id: I6963b00d9eecf49fb4578bcc75ad744c3099f045 Reviewed-on: https://chromium-review.googlesource.com/1125529 Commit-Ready: Slava Malyugin <slavamn@chromium.org> Tested-by: Slava Malyugin <slavamn@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org>
2018-07-04 04:01:03 +00:00
build = "build.rs"
x86_64: Add x86_64 setup code Change-Id: Ibdf83f8efcc92bf1f45ed9a5f95117fd9ae3ad5a Reviewed-on: https://chromium-review.googlesource.com/483868 Commit-Ready: Dylan Reid <dgreid@chromium.org> Tested-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org>
2017-04-21 00:33:17 +00:00
[dependencies]
crosvm: create a LinuxArch trait and use it for x86 This creates a trait that different architectures can implement to support running Linux VMs. In the implementation on X86 we remove some error and return errors from lower-level modules as appropriate. These modules now implement the Error trait so we can get meaningful descriptions without an extra error from the calling function. This still keeps all the ifdefs in linux.rs for now until we have another implementation to use for ARM. BUG=chromium:797868 TEST=./build_test passes on all architectures TEST=crosvm runs on caroline Change-Id: If24bcc83e25f9127d6aea68f9272e639296aad8b Reviewed-on: https://chromium-review.googlesource.com/952368 Commit-Ready: Sonny Rao <sonnyrao@chromium.org> Tested-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org>
2018-02-14 06:09:43 +00:00
arch = { path = "../arch" }
Limit types that can be read from guest memory Not all types are safe to read from guest memory. Any type with a reference or pointer will be initialized to random bits that don't refer to a valid address. This can cause dangling pointer and general unsafe behavior. To fix this, limit types that can be read with read_obj to those that implement the unsafe trait `DataInit`. Provide implementations of `DataInit` for intrinsic types that are obviously safe to initialize with random data. Implement the needed traits for bootparam types as they are read from the kernel image directly. Change-Id: I1040f5bc1b2fc4c58c87d8a2ce3f618edcf6f9b1 Signed-off-by: Dylan Reid <dgreid@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/540750 Reviewed-by: Zach Reizner <zachr@chromium.org>
2017-06-20 17:15:51 +00:00
data_model = { path = "../data_model" }
crosvm: move x86_64 arch specific stuff into the x86_64 crate This is in preparation to make different architectures implement a trait, but for now it's just moving code out of linux.rs and into x86_64 trait. A few new functions were required which will become part of the trait interface. There's still a lot of ugly ifdefs everywhere that should go away in subsequent CLs. BUG=chromium:797868 TEST=./build_test TEST=run crosvm on caroline Change-Id: Ifc95d4eb84f64ebacb4481a172524d94dc96b7bb Signed-off-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/942084 Reviewed-by: Zach Reizner <zachr@chromium.org>
2018-02-01 23:52:58 +00:00
devices = { path = "../devices" }
Revert "Revert "linux: Convert all virtio devices to PCI"" This reverts commit c8986f14a8dd9f256d6faed55996d955b50ff923. Re-land the virtio PCI conversion after the preceding fixes. BUG=chromium:854766 TEST=Boot crosvm on nami and kevin Change-Id: I3699e3ed1a45cecc99c51e352d0cf0c32bc4116f Signed-off-by: Daniel Verkamp <dverkamp@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1265862 Reviewed-by: Dylan Reid <dgreid@chromium.org>
2018-10-05 18:40:59 +00:00
io_jail = { path = "../io_jail" }
x86_64: Add x86_64 setup code Change-Id: Ibdf83f8efcc92bf1f45ed9a5f95117fd9ae3ad5a Reviewed-on: https://chromium-review.googlesource.com/483868 Commit-Ready: Dylan Reid <dgreid@chromium.org> Tested-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org>
2017-04-21 00:33:17 +00:00
kvm_sys = { path = "../kvm_sys" }
kvm = { path = "../kvm" }
sync: Mutex type with methods that panic instead of return error This CL adds a crate `sync` containing a type sync::Mutex which wraps the standard library Mutex and mirrors the same methods, except that they panic where the standard library would return a PoisonError. This API codifies our error handling strategy around poisoned mutexes in crosvm. - Crosvm releases are built with panic=abort so poisoning never occurs. A panic while a mutex is held (or ever) takes down the entire process. Thus we would like for code not to have to consider the possibility of poison. - We could ask developers to always write `.lock().unwrap()` on a standard library mutex. However, we would like to stigmatize the use of unwrap. It is confusing to permit unwrap but only on mutex lock results. During code review it may not always be obvious whether a particular unwrap is unwrapping a mutex lock result or a different error that should be handled in a more principled way. Developers should feel free to use sync::Mutex anywhere in crosvm that they would otherwise be using std::sync::Mutex. TEST=boot linux Change-Id: I9727b6f8fee439edb4a8d52cf19d59acf04d990f Reviewed-on: https://chromium-review.googlesource.com/1359923 Commit-Ready: David Tolnay <dtolnay@chromium.org> Tested-by: David Tolnay <dtolnay@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org>
2018-12-04 07:37:46 +00:00
sync = { path = "../sync" }
x86_64: Add x86_64 setup code Change-Id: Ibdf83f8efcc92bf1f45ed9a5f95117fd9ae3ad5a Reviewed-on: https://chromium-review.googlesource.com/483868 Commit-Ready: Dylan Reid <dgreid@chromium.org> Tested-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org>
2017-04-21 00:33:17 +00:00
sys_util = { path = "../sys_util" }
Remove the device manager and use the new resource allocator Allow IRQs to be assigned before creating device manager. For PCI, we need to add devices with interrupts before MMIO setup. Add the ability to tell the architecture device manager about IRQs that we have stolen. There was only one function in device_manager and all of its state is now delegated to the resource allocator, remove it. Change-Id: I9afa0e3081a20cb024551ef18ae34fe76a1ef39d Reviewed-on: https://chromium-review.googlesource.com/1089720 Commit-Ready: Dylan Reid <dgreid@chromium.org> Tested-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
2018-05-18 01:47:11 +00:00
resources = { path = "../resources" }
crosvm: move x86_64 arch specific stuff into the x86_64 crate This is in preparation to make different architectures implement a trait, but for now it's just moving code out of linux.rs and into x86_64 trait. A few new functions were required which will become part of the trait interface. There's still a lot of ugly ifdefs everywhere that should go away in subsequent CLs. BUG=chromium:797868 TEST=./build_test TEST=run crosvm on caroline Change-Id: Ifc95d4eb84f64ebacb4481a172524d94dc96b7bb Signed-off-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/942084 Reviewed-by: Zach Reizner <zachr@chromium.org>
2018-02-01 23:52:58 +00:00
kernel_cmdline = { path = "../kernel_cmdline" }
kernel_loader = { path = "../kernel_loader" }
x86_64: Add x86_64 setup code Change-Id: Ibdf83f8efcc92bf1f45ed9a5f95117fd9ae3ad5a Reviewed-on: https://chromium-review.googlesource.com/483868 Commit-Ready: Dylan Reid <dgreid@chromium.org> Tested-by: Dylan Reid <dgreid@chromium.org> Reviewed-by: Zach Reizner <zachr@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org>
2017-04-21 00:33:17 +00:00
libc = "*"
byteorder = "*"
x86_64: fill cache info in cpuid, stop spoofing CPU vendor id The fix passes through cache-related CPU entries 2, 4, 0x80000005 and 0x80000006 similar to how QEMU does it. Note passing this cpuid info itself is not sufficient unless CPU vendor is something Linux kernel recognizes. Therefore, I am removing cute spoofing of the vendor id, allowing host value to pass through. I believe it is generally a bad idea to spoof vendor id as lots of kernel and user space code gets confused and may take unoptimized paths. The corollary is that removing the spoofing may have unintended consequences correctness- and performance-wise. I would appreciate recommendation on additional testing. BUG=chromium:859678 TEST=lscpu in Guest, 'cargo test' Change-Id: I6963b00d9eecf49fb4578bcc75ad744c3099f045 Reviewed-on: https://chromium-review.googlesource.com/1125529 Commit-Ready: Slava Malyugin <slavamn@chromium.org> Tested-by: Slava Malyugin <slavamn@chromium.org> Reviewed-by: Dylan Reid <dgreid@chromium.org>
2018-07-04 04:01:03 +00:00
[build-dependencies]
cc = "=1.0.15"
Reference in a new issue Copy permalink