Ensure that every Cargo.toml dependency on a third-party crates.io crate
specifies at least a major version, or a minor version for 0.x crates,
to ensure that if a new major version is published, it cannot cause API
breaks.
The versions are selected to match the ones already in Cargo.lock, so
this should have no functional change, but it will help prevent new "*"
versions from being introduced via copy-and-paste.
For rationale, see the Cargo FAQ:
<https://doc.rust-lang.org/cargo/faq.html#can-libraries-use--as-a-version-for-their-dependencies>
`minijail`, `audio_streams`, and `cras` are left as "*" for now, since
they have unusual situations (imported from a submodule and/or replaced
at build time with ebuild magic).
BUG=None
TEST=tools/dev_container tools/presubmit
TEST=verify Cargo.lock is unchanged
Change-Id: Ifa18199f812f01d2d10bfb4146b3353c1a76527c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5555656
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Kernel images are often stored compressed because they can take up a
significant amount of disk space. One of the popular formats for this is
LZ4. Even though it does not offer the best compression ratio, it excels
at decompression speeds.
On arm64, kernels do not come with their own decompressor like they do
on x86. Instead, it is the job of the bootloader to decompress the
kernel before it is executed.
To this end, add crosvm support for LZ4 decompression of kernel images,
via the Rust-safe lz4_flex library. LZ4 file format is detected
automatically via one of its magic numbers. Otherwise crosvm will fall
back to loading the kernel as a raw image.
Some rough numbers using Android's Generic Kernel Image on Pixel 8:
* compresion rate: 49% (33MB -> 16MB)
* decompression time: 20-30ms
Given that the total VM boot takes about 1.5s, the overhead is more than
acceptable.
BUG=b:315141974
TEST=tools/dev_container tools/run_tests --platform=aarch64
Change-Id: I1030abe6fdf7087603cea9ac5273bf9136bad693
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5110323
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: David Brazdil <dbrazdil@google.com>
zerocopy 0.7.x has finally released as a stable version, uprev it
to allow some remaining structs to be derivable.
TEST=CQ
BUG=b:300969352
FIXED=b:300969352
Change-Id: I90f0dfb09494f875fef1cd11bfcbd48030846092
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4878761
Auto-Submit: Zihan Chen <zihanchen@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Zihan Chen <zihanchen@google.com>
Previously all of the zerocopy imports just used "*", but there are
API changes in zerocopy 0.7, so ensure we get a compatible version by
depending on 0.6 everywhere.
This is a no-op since Cargo.lock already specifies a 0.6.x version, but
it will prevent accidentally upgrading to 0.7.x without updating to the
new API.
BUG=b:301283548
TEST=cargo build
Change-Id: Ifd702d982a09b5083dddd666dc6f3052cba22214
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4878502
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Thie effort is splitted into multiple CLs, to reduce change size
and also make bisecing breakages easier.
TESTED=CQ only
BUG=b:204409584
Change-Id: Ie90f171bd5f74b732df3129e94733f3b34621092
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4210751
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Zihan Chen <zihanchen@google.com>
Previously, we were loading ELF kernels at the provided kernel_start
address plus the p_paddr (physical address) field of each program
header. This resulted in the kernel being loaded after a big gap of
zero bytes, which accidentally worked on x86_64 because 0x00 0x00
encodes a valid instruction, and the entry point was at the beginning of
the first section, so execution would effectively "nop slide" its way
from the supposed entry point all the way to the actual beginning of the
correct code. In addition, the Linux kernel entry point is compiled as
position-independent code, so the mismatched address did not matter.
Fix this by loading ELF kernels at whatever physical address they
specify, without adding any extra offset. The load_kernel() function
still accepts a start address, but this is now used simply to verify
that the ELF file does not try to load any sections outside of the
desired kernel region.
As a demonstration, we can look at the instructions at the kernel's
declared entry point (0x1000000 for a normal x86-64 Linux kernel in ELF
format) by attaching to the gdb stub and running:
(gdb) disas 0x1000000,+8
With the old behavior, we get purely 0x00 0x00 opcodes, decoding as:
0x0000000001000000: add BYTE PTR [rax],al
0x0000000001000002: add BYTE PTR [rax],al
0x0000000001000004: add BYTE PTR [rax],al
0x0000000001000006: add BYTE PTR [rax],al
With the new behavior, we get the correct entry point instructions:
0x0000000001000000: lea rsp,[rip+0x1203f51] # 0x2203f58
0x0000000001000007: lea rdi,[rip+0xfffffffffffffff2] # 0x1000000
BUG=b:234155022
TEST=cargo test -p kernel_loader
TEST=Boot x86-64 ELF vmlinux kernel
Change-Id: Iae4c8db022674e6311e54dffe479a1ed430a1ef4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3673612
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Anton Romanov <romanton@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This change contains the results of running
./tools/contib/cargo_refactor.py
This will break the next uprev, and needs to be synchronizized
with the corresponding ebuild changes in https://crrev.com/c/3248925
BUG=b:195126527
TEST=./tools/run_tests
Change-Id: Ied15a1841887bb8f59fba65b912b81acf69beb73
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3248129
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Use the crates.io implementation of tempfile instead of our own version.
Our reimplementation is kept in the tree for now in case of dependencies
outside of the crosvm tree; it can be removed later once those are fully
switched over to the crates.io implementation.
BUG=b:199204746
TEST=emerge-hatch crosvm
Change-Id: I07d3404239302ab9a17f4ddc82a9479b256e4eb4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3209839
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Replace the uses of read_struct() and read_struct_slice() with the
safe DataInit::from_reader() implementation.
BUG=b:197263364
TEST=./test_all
TEST=Boot bzImage kernel
TEST=Boot raw ELF kernel extracted with extract_vmlinux
Change-Id: I80f98243bfb58a7ae93e1686bc4d92b0cd485cda
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3108249
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This is very largely boilerplate, but changes some interfaces
to accept different parameters, esp using Descriptor.
BUG=b:162363783
TEST=./build_test
Change-Id: I81b513c0de9448c2de505fe5d3a61a29f4eccb78
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2342591
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
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>
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>
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: I4f6c91c966afc96fad634e355553ab90fc305261
Reviewed-on: https://chromium-review.googlesource.com/1519698
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>
