As pKVM and pvmfw development for x86 is ongoing, add initial support
for running VMs with pvmfw as the VM bootloader. For now only support
the --unprotected-vm-with-firmware development flag, for running regular
non-protected VMs with pvmfw, which doesn't require pKVM support.
Similarly to ARM, add a dedicated memory region for pvmfw to the x86-64
memory map. This region is located right below the PCI MMIO memory hole.
Its size is 4MB, like on ARM.
Similarly to ARM, the pvmfw entry point is at the beginning of the pvmfw
image, the normal x86-64 boot protocol is kept as is, and additionally
the VM payload (i.e. kernel) entry point is passed to pvmfw in the %rdi
register. This ABI is a subject to change, the final ABI for x86 pvmfw
is not defined yet.
BUG=b:354676864
TEST=1. Run a VM with "--unprotected-vm-with-firmware pvmfw_test.bin"
where pvmfw_test.bin begins with the "jmp *%rdi" instruction (2 bytes:
0xff 0xe7), i.e. pvmfw immediately jumping to the VM entry point.
Result: VM runs as usual.
2. Run a VM with "--unprotected-vm-with-firmware pvmfw_random.bin" where
pvmfw_random.bin contains just random data. Result: VM crashes.
Change-Id: Ib0ee998a99a0cf352a97222769b87be615419187
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5797353
Commit-Queue: Dmytro Maluka <dmaluka@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
If a guest memory region is misaligned, provide the guest memory address
and size of the region in the error message to make it more useful for
debugging.
BUG=b:358426674
Change-Id: Ia822d568724925b72624213a406a646f3f9e2d70
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5849386
Reviewed-by: maciek swiech <drmasquatch@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
On aarch64, we load BIOS payloads at offset 0x200000 because
cuttlefish's u-boot BIOS requires the FDT at offset zero. However, in a
separate use case, we are loading BIOS payloads that are OK with dynamic
FDT addresses, but might use the Gunyah hypervisor, which currently
requires the payload to be loaded at offset zero. One algorithm can't
satisfy both.
Both the u-boot setup and Gunyah ought to be made more flexible, but it
seems useful to make crosvm's behavior configurable. It lets us adjust
those use cases eventually without causing an immediate backwards
incompatability scramble.
A new "after-payload" mode is included that matches crosvm's RISCV FDT
address behavior and potentially helps with the TODO for >4GB VMs.
BUG=b:353758405
Change-Id: I886f47cf8e0a6b02218794615215a0e972a4ace2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5740018
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
For ioctl numbers that do not require any parameters, make ioctl_io_nr
and related macros generate a constant rather than a function with no
parameters. This makes the code that uses these constants more idiomatic
and also allows using the constants in match statements (see an example
in virtio/fs/passthrough.rs).
BUG=None
TEST=tools/dev_container tools/presubmit
Change-Id: Id52817528d770c5dbbe2ce7928c9f31a15c83d83
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5648647
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
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>
The tempfile crate is only used in tests, so it does not need to be in
the main [dependencies] section of any of our first-party crates.
Also fix a couple of [dev_dependencies] instances to the officially
documented [dev-dependencies] name for consistency.
BUG=None
TEST=cargo tree
Change-Id: I1dcb6be10c302baec4e8ebe6f72480f76e4e3760
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5521511
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
RAM snapshot size and overall snapshot time for a basic ubuntu VM right
after login:
* no compression: 619M 0.8s
* lz4 compression: 175M 1.2s
BUG=b:320753724
TEST=crosvm snapshot take --compress-memory /tmp/crosvm-snapshot /tmp/crosvm-control
Change-Id: I5dff9fe8744847fea872ad78347ac5f7d8b957e3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5190788
Reviewed-by: Elie Kheirallah <khei@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
The current SnapshotReader/Writer interface returns Files for raw
fragments. When we add snapshot encryption, we will need to return an
encrypting or decrypting streaming wrapper, and this won't be a File.
This CL changes the interface to return impl Read or impl Write. As
part of that, we also had to make a significant safety change to
how memory snapshots are taken.
Memory snapshots used to be written with FileReadWriteVolatile. This is
because we assume GuestMemory is always mutably borrowed by the guest,
and it is UB to have aliased references in Rust. While formally
undefined, the rough reasoning for this is that LLVM optimizations
assume noalias on mutable references, and if that is violated at
runtime, optimizations can result in changed behavior. In the snapshot &
restore case though, we know the guest is not running because its VCPUs
are stopped, so its mutable reference can be ignored (temporal overlap
for aliasing is required for UB to occur). Luckily for us, the host code
will never alias guest memory because up until this CL, we assumed that
was never safe.
Credit: thanks to fmayle@, who originally proposed using Read/Write in this
manner in a CL that added snapshot compression.
BUG=b:326170473
TEST=builds
Change-Id: Iafd9175f684bc197329a0f5aae57685f5cfd677e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5313630
Reviewed-by: Frederick Mayle <fmayle@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
If the data iterator hits an error, then we probably shouldn't continue
as if there was no remaining data.
BUG=b:307603892
Change-Id: Iad75974c3801d00acc95201d0686aa5f58cb6ea8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5214579
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Shin Kawamura <kawasin@google.com>
On linux, we can use `lseek`'s `SEEK_DATA` and `SEEK_HOLE` features to
skip hole in files. On a freshly booted VM, it is common that much of
the RAM is untouched. For an Ubuntu test VM 8 GiB RAM, this reduced the
snapshot size from 8 GiB to 655 MiB and the snapshot time from 12s to
270ms. Restore time is tricky to measure exactly, but it feels much
faster.
BUG=b:307603892
Change-Id: I28b67557c4b6faec9c829345447395832d290d1c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5182033
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
This removes some auto-generated safety comments, but should otherwise
be a no-op.
Change-Id: Ibfcf75c6e296367fe1a6114ce2047fb79e34041b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5178534
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
IoBuf is defined in a platform-specific way (it is either iovec on unix
or WSABUF for windows), so it fits into the mission statement of the
base crate, which is meant to be *the* platform abstraction layer in
crosvm.
IoBufMut and VolatileMemory/VolatileSlice are defined in terms of IoBuf,
so they are also moved into base for consistency. Every crate that uses
these types already depended on base, so no extra dependencies are
added, and a few can be removed.
BUG=b:312312646
TEST=tools/dev_container tools/presubmit
Change-Id: I4dddc55d46906dfc55b88e8e6a967d7e1c1922dd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5046605
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
These duplicate existing VolatileSlice and FileReadWriteAtVolatile
functionality. Removing them means that they don't need to be
reimplemented separately for each platform's MemoryMapping.
BUG=b:309020556
TEST=tools/dev_container tools/presubmit
Change-Id: Ia4332159461efc001b4e980fdb2a9984e852c931
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5019440
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
base::Pid is explicitly added since every platform has a process id
type.
Bug: 233233301
Test: tools/dev_container ./tools/presubmit
Change-Id: Id0d54fe06981c1dcbdee3f73b1241af74a26300f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4909061
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
This matches its new location in sys/linux, and it also more accurately
describes the trait, since the sealing functionality is specific to
Linux, not available on any other Unix-like platform.
Change-Id: If06fb7b6aacac80968c0b40bc4b48e62988c93a9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4969179
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Updates are made to source and documentation.
This more accurately represents the currently supported platforms of
Android/Linux and Windows, without unexpectedly including other
unix-like operating systems.
Command to reproduce:
$ find . -type f -not -path '*/\.git/*' | xargs -I {} sed -i 's/cfg(unix)/cfg(any(target_os = "android", target_os = "linux"))/g' {}
$ cargo fmt
md files manually updated to fix line lengths.
Renaming `unix` modules to `linux` will be done in a later CL.
Test: ./tools/dev_container ./tools/presubmit
Bug: b/298269162
Change-Id: I42c1bf0abf80b9a0df25551613910293217c7295
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4909059
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
Reviewed-by: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@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>
GuestAddress::unchecked_add() previously used a normal + operator to add
the two values, which got converted into a checked addition even in
release mode due to our use of `overflow-checks = true`. Explicitly call
the wrapping_add() function instead to ensure we get the natural binary
integer behavior, which can be compiled into a simple add instruction
without any extra checks.
Additionally, mark the function as #[inline] - even though the function
body is quite small, in practice, I observed the compiler emitting a
call instead of simply inlining the single instruction (at least in
non-LTO release builds).
This probably has very little impact in practice, but it should slightly
improve codegen in some critical paths for virtio descriptor processing.
BUG=None
TEST=tools/dev_container tools/presubmit
TEST=cargo build --release and observe no call in SplitQueue::add_used
Change-Id: Idad5acccf56b4428f8db890576e37e470e61584d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4679849
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is a new major version, and requires some code changes.
Change-Id: I294ce3604aad6e6dc5f50e33246b690e883c1e36
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4481294
Auto-Submit: Andrew Walbran <qwandor@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
This is supported since Rust 1.62.
Fixes the new derivable_impls clippy lint, added in Rust 1.67.
BUG=b:276487055
TEST=tools/clippy # with rust 1.68
Change-Id: I3696dd3cf4acbf9b5a2cfa8c2046e7656e13dbbd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4390735
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Gunyah needs explicit knowledge about which memory is used for protected
firmware, static swiotlb, or general purpose guest memory.
Hypervisor-agnostic, architecture-specific code creates the memory map
for guest VMs and doesn't presently have any mechanism pass this
information about the memory regions to the hypervisor.
Introduce MemoryRegionOptions which can be supplied by arch-specific
code. Subsequent commits will switch Arch code to use
new_with_options().
In the future, MemoryRegionOptions can be extended to support
guest memory layout decisions about whether the memory should be backed
by a restricted_memfd.
BUG=b:232360323
Change-Id: Id26bd645cb857accd69bb2db128c4874ce5c3e6f
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4379523
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Introduce a struct argument, MemoryRegionInformation, for use with
with_regions.
No functional change intended.
BUG=b:232360323
Change-Id: Icd40630c32878b3bd185aeeedcf9e1e9de20e20b
Suggested-by: Frederick Mayle <fmayle@google.com>
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4379522
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This is admittedly an odd feature with a narrow use case. It will lower
the risk of crash analysis tools accidentally trying to read guest
memory that has been unshared from the host (i.e. in a protected VM).
Hoperfully we'll eventually have a better solution, where we only mmap
the memory regions that are shared with the host. There is no hypervisor
support for that yet.
BUG=b:238324526
Change-Id: Iac7ed38aa52778a43ac5ba22bab5a3df7a554ee6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4251719
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
With the previous CLs migrating many functions and types to use
zerocopy, finally we can do a big clean up of`unsafe impl DataInit`.
We are down to 93 instances now from 230 at 5th CL in this series.
Also fixes a bug introduced previously in this series where I set
the trait bound of a few write_at_addr unsafe functions to
`FromBytes` when `AsBytes` should also be required.
TEST=CQ
BUG=b:204409584
Change-Id: I6658dd246a8932493ef6a652054a23ecfde76198
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4237765
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Zihan Chen <zihanchen@google.com>
`crosvm snapshot take ...` will write the contents of guest memory to a
file and `crosvm restore apply ...` will read that file to overwrite
guest memory.
To start with, the file is chosen by adding a ".mem" extension to the
snapshot file path. We should consider a better approach in the future,
maybe put them both in a tar file or have the user supply a directory
instead of a file path.
BUG=b:266514791
Change-Id: Ic05f94223fb74674bd57dcd2f848055b31eb5fdc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4215313
Reviewed-by: Elie Kheirallah <khei@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
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>
This is a reland of commit d39e5811df
This change mark VolatileRef as deprecated instead of removing it
completely. This change also removed all related methods and functions
using VolatileRef that libcras don't use.
Original change's description:
> data_model: remove VolatileRef
>
> All uses except in test code have been eliminated, so we can remove it
> now.
>
> This was an unsafe abstraction, and we have better alternatives (such as
> the read_obj()/write_obj() functions) that do not create a long-lived
> mutable reference that could easily alias other slices.
>
> BUG=None
> TEST=tools/presubmit --all
>
> Change-Id: I84f1e2487d6211ce24b8fc992fa7675765870132
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3824000
> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
> Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
> Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
TESTED=CQ
BUG=b:204409584
FIXED=b:236759218
Change-Id: I4019870a2321fcd8610669862b5e6ed9bf7c2282
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4215512
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Zihan Chen <zihanchen@google.com>
When we run FIO stress test with virito-blk, we found sometimes crosvm
would read an invalid "avail_index" from available ring of virtqueue.
This invalid "avail_index" would lead to subsequent "avail_len" check
fails and cause all filled descriptor won't be processed, and even worse
is the "vring_need_event" would always fail in Kernel virtio driver and
the virtqueue could be blocked forever if the feature
"VIRTIO_RING_F_EVENT_IDX" is enabled.
After a further investigation, we found the issue is related with rustc
optimization level, when opt_level=0, function 'read_unaligned' would
finally call glibc function 'memcpy' to read the value. While 'memcpy'
could break the read atomicity of u16 type data as the data is read one
byte by one byte. When opt_level >= 1, the 'read_unaligned' is optimized
to call a single 'mov' instruction to read the u16 data, so the issue
is gone.
we found 'read_volatile' function would be compiled to a single 'mov'
instruction in any optimization level. Atomic looks to be more right
solution to fix the issue, but we utilize this finding about volatile
as a workaround.
BUG=b:258349128
TEST=Run 12-hours FIO stress test in crosvm Linux VM and no packet loss
are found.
Change-Id: Iae5e4b29fe34ed9f4437afa4fe4e43a3c337e2df
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4021759
Commit-Queue: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This function was used to check if the memfd_create() function worked in
order to skip tests on very old kernels (before Linux 3.17 from 2014).
All kernels older than 3.17 are EOL now, so we can reasonably require a
more recent kernel version.
Removing the checks will ensure that all tests actually pass rather than
being silently skipped.
BUG=None
TEST=crosvm CQ
TEST=tools/presubmit --all
Change-Id: I92695127061406901bb02b1012f2c14ee9afc705
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4126247
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
These should be written as ChromeOS and ChromiumOS (without the space)
to match the updated branding. The copyright headers were already
migrated to the new style (https://crrev.com/c/3894243), but there were
some more instances left over.
BUG=None
TEST=tools/cargo-doc
Change-Id: I8c76aea2eb33b2e370ab71ee9b5cc0a4cfd00585
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4129934
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This patch refactors do_in_region a function find_region that does not
take a closure as an argument, but instead returns the region.
BUG=None
TEST=tools/presubmit --all
Change-Id: I1ca11b513d42836410d363ccdf1cda61edc33ec8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4019232
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Michael Sammler <sammler@google.com>
This reverts commit d39e5811df.
Reason for revert: libcras still uses VolatileRef and needs to be fixed before we can remove it
Original change's description:
> data_model: remove VolatileRef
>
> All uses except in test code have been eliminated, so we can remove it
> now.
>
> This was an unsafe abstraction, and we have better alternatives (such as
> the read_obj()/write_obj() functions) that do not create a long-lived
> mutable reference that could easily alias other slices.
>
> BUG=None
> TEST=tools/presubmit --all
>
> Change-Id: I84f1e2487d6211ce24b8fc992fa7675765870132
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3824000
> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
> Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
> Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Bug: None
Change-Id: I867cd1adff6c0c895791833432acd4a64aef0506
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/4018409
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
All uses except in test code have been eliminated, so we can remove it
now.
This was an unsafe abstraction, and we have better alternatives (such as
the read_obj()/write_obj() functions) that do not create a long-lived
mutable reference that could easily alias other slices.
BUG=None
TEST=tools/presubmit --all
Change-Id: I84f1e2487d6211ce24b8fc992fa7675765870132
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3824000
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
The pVM firmware memory region is allocated before
AARCH64_PHYS_MEM_START, but several parts of the code were assuming that
all memory was contiguous and after that.
BUG=b:244553205
TEST=Patched into AOSP and ran some VMs.
Change-Id: I8caefc9cae79c98ea62ee02a506b1b485d3f09a6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3921604
Reviewed-by: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Jiyong Park <jiyong@google.com>
The current crosvm implementation is using
`GuestMemory::checked_offset()` for the following two cases:
(1) To get a valid `GuestAddress` representing `addr + offset`.
(2) Guarantee that the memory range `[addr, addr+offset]` is valid.
However, using `checked_offset()` for the case (2) is wrong because the
method only checks if the end address `addr+offset` is valid and doesn't
check if an invalid region exists between `addr` and `addr+offset`.
So, this CL adds `GuestMemory::is_valid_range()` to replace the (2)
cases.
BUG=b:251753217
TEST=cargo test in vm_memory
TEST=start a vm with virtio devices
Change-Id: I21bce5d1c60acdff79284cdad963849a6e19e19c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3945520
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This is generally more useful when it shows up in log messages.
BUG=b:244553205
TEST=tools/dev_container tools/run_tests
Change-Id: Idbaa58f7a9fdb8e69212074fb5853da9098a82fb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3921603
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Andrew Walbran <qwandor@google.com>
