The Chrome OS Rust toolchain has been updated to Rust 1.32.0[1]; update
the version in Kokoro and the rust-toolchain file to match.
It looks like there is also one minor formatting change (again).
BUG=None
TEST=Build kokoro image and run tests
[1]: https://chromium-review.googlesource.com/1432733
Change-Id: I5669d99463618e19cb5e957171560dbea33bd5b8
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1470913
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Update the default Rust toolchain to the version specified in the
rust-toolchain file (which is part of the crosvm source directory, not
baked into the Docker image) during each kokoro run.
This will let us seamlessly update rust-toolchain without breaking the
builds using the existing kokoro Docker image once this change is in
place.
BUG=None
TEST=Build image with 1.31.0, then run test with rust-toolchain 1.32.0
Change-Id: If4f6dffc20af33011d2a96a0cf6b3db3582a2fd0
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1470914
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
PluginVm uses /dev/urandom, so we need to mount it, along with
/dev/zero, /dev/null, and /dev/full.
Note that we are not using minijail's mount_dev() API because it will
try to create tmpfs without using MS_NODEV flag and, since crovm may not
have CAP_SYS_ADMIN capability, Chrome OS LSM will stop it. So we rely on
the parent process to have minimal set of devices present and bind-mount
those into the jail.
BUG=b:117989168
TEST=cargo test --features=plugin
Change-Id: I6d8ab122c56614a8f7dbfe3d0eb8ed33532dc6a7
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1447551
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
I was skimming the gpu flag code (tpm will need something similar) and
found the way resource_bridge_wl_socket is used misleading. The same
variable is declared in two different places depending on whether
building with gpu. This CL combines them into one `let` statement.
Also moved the generic param onto None which comes out more readable
after rustfmt while still providing helpful context for the reader.
TEST=cargo check && cargo check --features gpu
Change-Id: I57a1ae214947475efa7bf01ab123a71a58411244
Reviewed-on: https://chromium-review.googlesource.com/1470915
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Allow --tap-fd to be given mutliple times, a different virtual network
card will be added each time the flag is given.
Additionally, --tap-fd is no longer mutually exclusive with --host-ip,
etc.
Bug=chromium:931470
Test=booted cuttlefish device with multiple network cards
Change-Id: I4108f97c7f4b19db12fcb3c533088a04a58e56db
Reviewed-on: https://chromium-review.googlesource.com/1469222
Commit-Ready: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This exports a new C API to resize a disk image. The new function is
intended to only expand (increase in size) to avoid accidentally
truncating user data due to bugs elsewhere.
BUG=chromium:858815
TEST=build_test.py
Change-Id: I6f834209aba693618e0f51d920e7b73d4f2a9dfc
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1464384
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The glibc realloc() implementation may call the mremap syscall in some
cases; we currently allow mremap in x86_64/common_device.policy but not
the arm equivalent, but this path appears to be reachable on any Linux
platform[1]. Add mremap to the arm policy as well for consistency.
mremap is no more powerful than the existing mmap and munmap syscalls,
so I believe this is safe to allow for all device processes.
Also reorder the mmap2 line in the arm policy so it is in alphabetical
order and can be more easily compared to the x86_64 policy.
BUG=chromium:927919
TEST=Boot crosvm on kevin
[1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l2854
Change-Id: Ie51a21baf30d3e37ce3adacf8e255f981613543d
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1459020
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Remove a bunch of TODOs that mention things that the C++ test does that
we don't need to do, and replace a TODO with a detailed explanation of
why the code behaves as it does.
BUG=chromium:908689
TEST=None; comment-only change
Change-Id: I6791fbe329e8cdd1cac0d55b7770927d60c051c4
Reviewed-on: https://chromium-review.googlesource.com/1454141
Commit-Ready: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Some of the variants of the CommandCounter enum are not currently used;
add a directive to ignore dead code warnings for these variants, since
they are defined by the hardware/spec and may be used in the future.
BUG=None
TEST='cargo build' executes without warnings
Change-Id: I72b6cd24722de801ebfe63bb7419c4e972463082
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1454139
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Miriam Zimmerman <mutexlox@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The default panic hook prints panic information and a backtrace to
stderr, where it gets dropped into /dev/null in the typical crostini
context.
This change adds a panic hook that will call the default panic hook
with stderr redirected to a pipe, which will then get forwarded to
syslog.
The new hook also forces an abort at the end to ensure the crash
reporter sees the panicked crosvm process, which will generate a
minidump for later debugging.
TEST=manually add panic!() observe /var/log/messages
BUG=None
Change-Id: I4e76afe811943e55cec91761447e03b949a674a4
Reviewed-on: https://chromium-review.googlesource.com/1440881
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Based on Linux boot protocol references:
- x86: Documentation/x86/boot.txt
- arm: Documentation/devicetree/bindings/chosen.txt
BUG=None
TEST=Boot Alpine Linux netboot initrd on x86_64 and aarch64
Change-Id: If4730765638f0a0b8bb8f63203c98e4765a354ee
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1407221
Tested-by: kokoro <noreply+kokoro@google.com>
This will allow placement of the initrd after the end of the device tree
blob in the next patch.
This also moves the load of the fdt into setup_system_memory() so that
the position of the initrd can be calculated (in the next patch) before
calling configure_system().
BUG=None
TEST=Boot Termina on x86-64
Change-Id: I6dcfce3aa48ae0932157a40fa28ea9fb384263c8
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1443634
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
EXT_sRGB_write_control was not getting advertised due to virgl not
performing EGL initialization. Move crosvm over to using the normal
virgl EGL initialization path.
BUG=chromium:925569
TEST=piglit/bin/fbo-srgb
Change-Id: I1acc5823ef1922395f1a6bf8e7996b23ee4c3632
Reviewed-on: https://chromium-review.googlesource.com/1446932
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This allows decoupling input from the wayland socket while using a
standard virtio device for it. The proposed virtio input spec can be
found at
https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-input.pdf, it
has already been implemented in qemu and (guest) kernel support exists
since version 4.1.
This change adds the following options to crosvm:
--evdev: Grabs a host device and passes it through to the guest
--<device>: Creates a default configuration for <device>,
receives the input events from a unix socket. <device> can be
'keyboard', 'mouse' or 'trackpad'.
Bug=chromium:921271
Test=booted on x86 linux and manually tried virtio-input devices
Change-Id: I8455b72c53ea2f431009ee8140799b0797775e76
Reviewed-on: https://chromium-review.googlesource.com/1412355
Commit-Ready: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
As reported by the Firecracker team, the block device model doesn't
check if an I/O request starts before the end of the disk but extends
beyond it. For writes to disks backed by raw files, this could end up
unintentionally extending the size of the disk.
Add bounds checks to the request execution path to catch these
out-of-bounds I/Os and fail them. While we're here, fix a few other
minor issues: only seek for read and write requests (the 'sector' field
of the request should be ignored for flush, write zeroes, and discard),
and check for overflow when performing the shifts to convert from
sectors to bytes.
BUG=chromium:927393
TEST=cargo test -p devices block
Change-Id: I0dd19299d03a4f0716093091f173a5c507529963
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1448852
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Some IOCTL macros are define to accept a parameter, EVIOCGBIT is an
example. This commit adds the ability to generate functions that
accept any number of arguments to generate the IOCTL number.
Bug=chromium:921271
Test=cargo test -p sys_util
Change-Id: I966a3ac85e05764acff5d61cf85dc95b2b70ec20
Reviewed-on: https://chromium-review.googlesource.com/1406812
Commit-Ready: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This plumbs in minijail_mount_dev() to allow mounting minimal set of
devices, such as full, zero, urandom, etc. in the jail.
BUG=b:117989168
TEST=cargo test -p io_jail
Change-Id: I072347a5eedab32d1fad6255c4e18e0242b9ac9f
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1447330
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
By default virglrenderer logs to stderr with VREND_DEBUG. dup stdout
which is logged via logger to stderr so that virglrenderer logs can be
seen.
BUG=chromium:925590
TEST=cat /var/log/messages
Change-Id: I3e1a5056dab9cfd895867b1835b421b144ee536b
Reviewed-on: https://chromium-review.googlesource.com/1441352
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The fork::tests::panic_safe unit test has been hanging intermittently in
CQ runs. The root cause isn't understood yet, but the most likely
explanation seems to be that the wait_process helper is hanging.
There should be only two causes for that hang: either the cloned process
is not exiting, or the wait() call in wait_process is not returning.
The wait() should only hang if another thread has already reaped the
cloned process.
In order to help debug the issue, change the general wait() to a
waitpid() on the specific cloned process ID. This will give us more
information about what happens when the test fails - if the waitpid()
returns ECHILD instead of hanging, this will indicate that something
else is waiting on our child process and racing with our wait().
BUG=chromium:925725
TEST=cargo test --release -p sys_util panic_safe
Change-Id: Ib25d88b35b16c75d4d8fe62fc779c9470303368a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1444317
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Logically, each VCPU is using GuestMemory, which holds a ref count to
the underlying memory mappings. This change formalizes this by giving an
actual reference of GuestMemory to each Vcpu struct.
This change is needed because the Vm can go out of scope and clean up
its reference, but the Vcpus may still be running, triggering an EFAULT
and a lot of confused days spent debugging.
TEST=With the unwind panic handler, trigger a panic right after the
final vcpu thread barrier. If the VCPU threads do not complain
about EFAULT (errno 14), this change worked.
BUG=None
Change-Id: I6289147de0adde61c81630357701487937b17ade
Reviewed-on: https://chromium-review.googlesource.com/1441355
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This device tree is derived from the Android fstab file which is
provided via command line flag.
BUG=chromium:922737
TEST=None
CQ-DEPEND=CL:1415390
CQ-DEPEND=CL:1415270
Change-Id: Idd007c844f84cab3ff37be16a718f14e5f630312
Reviewed-on: https://chromium-review.googlesource.com/1370058
Commit-Ready: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The Ac97 device provides the guest with an audio playback device. All
input devices are stubbed out. Only playback at 48kHz is supported.
The device is emulated by `Ac97Dev` which interfaces with the PCI bus.
`Ac97Dev` uses `Ac97` to drive audio functions and emulate the device
registers. Physical Ac97 devices consist of two parts, the bus master
and a mixer. These two sets of registers are emulated by the
`Ac97BusMaster` and `Ac97Mixer` structures.
`Ac97BusMaster` handles audio samples and uses `Ac97Mixer` to determine
the configuration of the audio backend.
BUG=chromium:781398
TEST=crosvm run --disable-sandbox --null-audio --rwdisk gentoo.ext4 -c2
-m2048 -p 'root=/dev/vda snd_intel8x0.inside_vm=1
snd_intel8x0.ac97_clock=48000' vmlinux.bin
and play audio with aplay -d2 -Dhw:0,0 -f dat /dev/urandom
CQ-DEPEND=CL:1402264
CQ-DEPEND=CL:1421588
CQ-DEPEND=CL:1433794
CQ-DEPEND=CL:1432835
Change-Id: I9985ffad753bccc1bf468ebbdacec0876560a5e0
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1366544
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
After trying symlinks and bind-mounts and various other shenanigans,
give up and move the crosvm working directory to a relative path that is
the same as in the chrome OS chroot.
This allows other crates in the cros checkout to find the crosvm crates
they depend on.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I643497f08c59328e02775ad3ac0ef9feafbf2930
Reviewed-on: https://chromium-review.googlesource.com/1436595
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Each device (Bus, Pci, Proxy, etc), gets a debug label associated with
it. When a child is spawned, the debug label for it is stored in
a map with the child's pid as the key. If a SIGCHLD is handled, this map
is used to print a more helpful message about exactly which child died.
BUG=None
TEST=run with sandboxing and a faulty child device
check logs for message about child died
the child should have a debug label
Change-Id: I61fbbee0a8e701249533a7a3a6a1ad48840f12e5
Reviewed-on: https://chromium-review.googlesource.com/1432835
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Some crates that are needed for crosvm need crates that live inside the
crosvm directory. To allow those crates to be used, add a symlink that
allows access to the crosvm source code from a path equivalent to that
used inside the Chrome OS chroot.
In particular, the cras crate is needed by devices and devices needs the
data_model and sys_util crates. Creating a platform/crosvm directory
parallel to the third_party/adhd directory lets the build of the cras
crates find their dependencies.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I2a1e28638e80c8008b1ecc29c2b0b69cba1c13e2
Reviewed-on: https://chromium-review.googlesource.com/1433518
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
This CL adds a "tpm" Cargo cfg to crosvm which enables a TPM device
backed by libtpm2 simulator.
Tested by running the following inside cros_sdk:
LIBRARY_PATH=~/src/minijail LD_LIBRARY_PATH=~/src/minijail \
cargo run --release \
--features tpm \
-- \
run \
-r rootfs.ext4 \
--seccomp-policy-dir seccomp/x86_64/ \
-p init=/bin/bash \
-p panic=-1 \
--disable-sandbox \
vmlinux.bin
with a Linux image built from CL:1387655.
The TPM self test completes successfully with the following output:
https://paste.googleplex.com/5996075978588160?raw
Justin's TPM playground runs with the following trace output.
https://paste.googleplex.com/4909751007707136?raw
Design doc: go/vtpm-for-glinux
TEST=ran TPM playground program inside crosvm
TEST=local kokoro
BUG=chromium:911799
Change-Id: I2feb24a3e38cba91f62c6d2cd1f378de4dd03ecf
Reviewed-on: https://chromium-review.googlesource.com/1387624
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Under the old command, the build would fail with:
Step 15/25 : COPY pkgconfig/* /usr/lib/pkgconfig
COPY failed: no source files were specified
The Docker documentation at
https://docs.docker.com/v18.03/engine/reference/builder/
explains:
Note: If you build using STDIN (docker build - < somefile), there is
no build context, so COPY cant be used.
TEST=it built successfully
Change-Id: I4d9fcb085009f4a47d7caecabf6eb711f5cab6b7
Reviewed-on: https://chromium-review.googlesource.com/1431356
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>
Together, these allow tests to create a FakeTimerFd that they can
trigger at a particular point in the test code, without having to rely
on sleep()s or other racy methods.
BUG=None
TEST=Unit tests for FakeTimerFd + dependent CL.
Change-Id: I14381272a6d75bebcdedb0a329a017a2131a3482
Reviewed-on: https://chromium-review.googlesource.com/1413830
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Not all tests can run on arches other than x86, annotate them
accordingly.
BUG=None
TEST=cargo test -p kvm
Change-Id: I38c90f1431b7fbd9059f5c309dc28264bbbcdb99
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1419206
Tested-by: kokoro <noreply+kokoro@google.com>
Update the readme to indicate that crosvm starts in multiprocess mode by
default.
Also fix a few typos I spotted while skimming the rest of the document.
BUG=None
TEST=None
Change-Id: Ia3992ec7cbf27be984269f5399d48e7fd5c6fc8f
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1428339
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
`libc::c_char` is `u8` instead of `i8` in arm, the test should use
`libc::c_char` directly.
Test unit tests with different architectures.
BUG=chromium:907520
TEST=$ FEATURES=test emerge-{kevin,eve} sys_util
Change-Id: Ie70da89470487d95675cb06b761e9ae9057bc38f
Reviewed-on: https://chromium-review.googlesource.com/1430400
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
On KVM implementations that use a paravirtualized clock (e.g. x86), a flag
must be set to indicate to the guest kernel that a VCPU was suspended. The
guest kernel will use this flag to prevent the soft lockup detection from
triggering when this VCPU resumes, which could happen days later in real time.
BUG=chromium:920875
TEST=inside VM `sha256sum /dev/urandom`, `crosvm suspend`, wait 30
seconds, `crosvm resume`
Change-Id: Id479ec0c26c17499ce0d638185a79e7b19ccc69c
Reviewed-on: https://chromium-review.googlesource.com/1417190
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This ioctl will be used to resolve an issue where the jump forward in
kvmclock on suspended VCPUs upon resume triggers the soft lockup
detection. Using this ioctl prevents this detection from triggering,
preventing a kernel panic on resume.
TEST=cargo test -p kvm
BUG=chromium:920875
Change-Id: Id1402a9d67d790e5e7e8655f2e5916210cc6e7cc
Reviewed-on: https://chromium-review.googlesource.com/1415849
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This change adds the suspend and resume commands to crosvm, as well as
corresponding VmRequest variants and VCPU loop support. When a request
triggers a VmRunMode change, the Mutex guarded shared VmRunMode variable
is mutated and the associated Condvar is notified. Each VCPU thread is
interrupted to kick it out of the KVM_RUN call and checks the VmRunMode,
If the VCPU was already suspended by waiting for the Condvar, the
notify_all call will wake up the thread, upon which the VCPU thread can
respond to the new mode.
TEST=crosvm suspend/crosvm resume
BUG=chromium:920875
Change-Id: Ibbeb748ab0d64402c7196890815e8e1cb4dfca38
Reviewed-on: https://chromium-review.googlesource.com/1416317
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The Condvar wrapper exposed by this change is analogous to the Mutex
wrapper in this crate. Instead of a Result being returned in the case of
a poisoned Mutex, a panic is triggered.
TEST=cargo build
BUG=chromium:920875
Change-Id: Id8bd6bc2891bfc5c8ce334fbdb482ef40500f2d7
Reviewed-on: https://chromium-review.googlesource.com/1416316
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
A future change will allow crosvm to play audio through cras. To do that
it needs to use some crates that live in the adhd repository. Add the
repository to the kokoro image at a path where Cargo can find the
crates.
Change-Id: I1542090ba0db6fd0f3ac60dcc2e7bb35502a4944
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1429311
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
To support eclass migration for crosvm ebuild from crate to cros-rust.
This CL need to be built with cros-rust version crosvm ebuild.
- Upgrage crate cc from 1.0.15 to 1.0.25.
- Change local tempdir version from 0.3.5 to 0.3.7 for ebuild
integration.
- Remove 9s directory since it's moved to platform2.
BUG=chromium:781398
BUG=chromium:907520
TEST=Run $ FEATURES=test emerge-eve crosvm
in a clean chroot
CQ-DEPEND=CL:1421303
Change-Id: Iab615b555a51f8020e5efae1cc40ac6b54ea87f2
Reviewed-on: https://chromium-review.googlesource.com/1421237
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
