Split sub-crates under crosvm root directory into several independent
workspaces for adding ebuild files for those crates.
data_model and sys_util could only be built by emerge after creating
their ebuilds.
BUG=chromium:916921
TEST='emerge-eve crosvm'
TEST=Run 'cargo build' under crosvm directory
Change-Id: I2dddbbb7c7344e643183a5885e867f134b299591
Reviewed-on: https://chromium-review.googlesource.com/1385972
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Every implementation of Fn also implements FnMut, so if some callback
can be passed to GuestMemory::with_regions then it could also have been
passed to GuestMemory::with_regions_mut.
This CL removes GuestMemory::with_regions and renames with_regions_mut
to with_regions.
TEST=cargo check
Change-Id: Ia4f168ff4eb4d45a5ee8f9413821ae244fb72ee1
Reviewed-on: https://chromium-review.googlesource.com/1378688
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
We updated the production toolchain from 1.30 to 1.31 in CL:1366446.
This CL does the same upgrade for the local developer toolchain and
Kokoro.
The relevant changes are in rust-toolchain and kokoro/Dockerfile.
The rest are from rustfmt.
TEST=cargo fmt --all -- --check
TEST=as described in kokoro/README.md
Change-Id: I3b4913f3e237baa36c664b4953be360c09efffd4
Reviewed-on: https://chromium-review.googlesource.com/1374376
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add the minimal amount of functionality needed for audio threads that
need to run with real time priority.
Change-Id: I7052e0f2ba6b9179229fc4568b332952ee32f076
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1366542
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This CL removes 300 lines of parsing code and 200 lines of tests of
parsing code by using the parsers provided by Syn, which we already use
in implementing our other custom derives.
TEST=cargo test poll_token_derive
TEST=cargo check crosvm
Change-Id: Ie2743b1bbb1b374326f9845fc37fc578b178c53d
Reviewed-on: https://chromium-review.googlesource.com/1365112
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
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>
Hopefully the changes are self-explanatory and uncontroversial. This
eliminates much of the noise from `cargo clippy` and, for my purposes,
gives me a reasonable way to use it as a tool when writing and reviewing
code.
Here is the Clippy invocation I was using:
cargo +nightly clippy -- -W clippy::correctness -A renamed_and_removed_lints -Aclippy::{blacklisted_name,borrowed_box,cast_lossless,cast_ptr_alignment,enum_variant_names,identity_op,if_same_then_else,mut_from_ref,needless_pass_by_value,new_without_default,new_without_default_derive,or_fun_call,ptr_arg,should_implement_trait,single_match,too_many_arguments,trivially_copy_pass_by_ref,unreadable_literal,unsafe_vector_initialization,useless_transmute}
TEST=cargo check --features wl-dmabuf,gpu,usb-emulation
TEST=boot linux
Change-Id: I55eb1b4a72beb2f762480e3333a921909314a0a2
Reviewed-on: https://chromium-review.googlesource.com/1356911
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Now that libc includes the fallocate64 function declaration that we
need, we can drop our own declaration and resolve the TODOs.
BUG=None
TEST=cargo build
Change-Id: I7548a561d672739fa7cdd7eb996ad2b2e307d69a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1352866
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
File exposes sync_all() and sync_data() functions, which map to fsync()
and fdatasync(), but these functions are not in a trait (they are just
implemented directly on File), so they can't be implemented and used in
a generic way for QcowFile.
Add a new trait, FileSync, that exposes a fsync() function that may be
used in the virtio block model. Previously, we were translating a block
flush request into a call to File's flush() function, but this just
flushes internal Rust library buffers to the file descriptor; it didn't
actually result in a fsync() call. Using the new trait, we can cause an
actual fsync() to occur for raw files, as intended. QcowFile was
already safe, since its flush() function actually calls sync_all() under
the hood.
BUG=None
TEST=sync with raw disk and verify fsync() in strace output
Change-Id: I9bee2c0d2df3747aac1e7d9ec7d9b46a7862dc48
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1297839
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Our branch of the 3.18 kernel has FALLOC_FL_PUNCH_HOLE disabled for the
ext4 filesystem, which means that systems running that kernel always
take the fallback path of writing buffers full of zeroes. This is not
necessary for the Discard command, since it is just a hint and is not
required to actually zero the blocks.
Split the WriteZeroes trait up into a new PunchHole trait, which
corresponds to fallocate() with FALLOC_FL_PUNCH_HOLE, and use the new
trait to implement the virtio block Discard command.
BUG=chromium:896314
TEST=`mkfs.btrfs /dev/vdb` and verify the desired fallocate() is used
and no write() calls are issued when inducing a failure
Change-Id: I67fd9a132758d8d766531ccca8358c7fe67b0460
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1286224
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Allow seeking to the next hole or data region in File and QcowFile.
BUG=None
TEST=None
Change-Id: I16e77e4791aa85b4cc96f38327026cd93f02b7e1
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1274147
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Some filesystems do not support FALLOC_FL_ZERO_RANGE; in particular,
encrypted files on ext4 fail this request with -EOPNOTSUPP. Use
fallocate with FALLOC_FL_PUNCH_HOLE instead, which is more widely
supported.
BUG=None
TEST=strace crosvm using qcow files on encrypted ext4 and verify that
fallocate(FALLOC_FL_PUNCH_HOLE) is issued when required.
Change-Id: Idffabc75ea0e1153efbb13cec8b4a25570427235
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1250022
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Now that cargo fmt has landed, run it over everything at once to bring
rust source to the standard formatting.
TEST=cargo test
BUG=None
Change-Id: Ic95a48725e5a40dcbd33ba6d5aef2bd01e91865b
Reviewed-on: https://chromium-review.googlesource.com/1259287
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Rust's libc crate exports the default off_t definition on 32-bit
platforms, rather than the _FILE_OFFSET_BITS=64 variant, so we need to
explicitly use the 64-bit API to get support for files larger than 2 GB.
The Rust libc crate does not currently export fallocate64, so declare it
ourselves for now. This declaration can be removed once fallocate64 is
added upstream.
BUG=chromium:850998
TEST=Run fstrim on Kevin (32-bit ARM) and verify it works
Change-Id: Id0aa7a6e7e6080f4c53e10c3ad1d105f15ee2549
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1238850
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The Scm object was made to reduce the number of heap allocations in
the hot paths of poll loops, at the cost of some code complexity. As it
turns out, the number of file descriptors being sent or received is
usually just one or limited to a fixed amount that can easily be covered
with a fixed size stack allocated buffer.
This change implements that solution, with heap allocation as a backup
in the rare case that many file descriptors must be sent or received.
This change also moves the msg and cmsg manipulation code out of C and
into pure Rust. The move was necessary to allocate the correct amount
of buffer space at compile time. It also improves safety by reducing the
scope of unsafe code. Deleting the code for building the C library is
also a nice bonus.
Finally, the removal of the commonly used Scm struct required
transitioning existing usage to the ScmSocket trait based methods. This
includes all those changes.
TEST=cargo test
BUG=None
Change-Id: If27ba297f5416dd9b8bc686ce740866912fa0aa0
Reviewed-on: https://chromium-review.googlesource.com/1186146
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This allows users to only arm timers if not already armed.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I8d7c6a7643a2ae2ce4b5679107bfd2be6e4adf3a
Reviewed-on: https://chromium-review.googlesource.com/1214442
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When setting up IO, accept an optional PciRoot device to put on the IO
bus.
For aarch64, it's currently ignored. For x86_64, it will be added at
0xcf8.
break up mmio device creation and registration
Moving forward registration will be handled by the architecture specific
code. However, creation will be handled by the common code. To make that
easier split up the two steps so a list of devices is created, then each
is registered later.
Start moving to a model where the configuration generates a set of
components that are passed to the architecture. The architecture will
crate a VM from the components.
Break up the big run_config function and move architecture specific
parts to the various architectures.
This doesn't refactor the function calls each architecture makes, but
moves the setup flow in to the arch impls so that they can diverge in
the future.
Change-Id: I5b10d092896606796dc0c9afc5e34a1b288b867b
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1099860
Commit-Ready: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Implement a policy for the balloon device so that it starts taking
memory away from the VM when the system is under low memory conditions.
There are a few pieces here:
* Change the madvise call in MemoryMapping::dont_need_range to use
MADV_REMOVE instead of MADV_DONTNEED. The latter does nothing when
the memory mapping is shared across multiple processes while the
former immediately gives the pages in the specified range back to the
kernel. Subsequent accesses to memory in that range returns zero
pages.
* Change the protocol between the balloon device process and the main
crosvm process. Previously, the device process expected the main
process to send it increments in the amount of memory consumed by the
balloon device. Now, it instead just expects the absolute value of
the memory that should be consumed. To properly implement the policy
the main process needs to keep track of the total memory consumed by
the balloon device so this makes it easier to handle all the policy in
one place.
* Add a policy for dealing with low memory situations. When the VM
starts up, we determine the maximum amount of memory that the balloon
device should consume:
* If the VM has more than 1.5GB of memory, the balloon device max is
the size of the VM memory minus 1GB.
* Otherwise, if the VM has at least 500MB, the balloon device max is
50% of the size of the VM memory.
* Otherwise, the max is 0.
The increment used to change the size of the balloon is defined as
1/16 of the max memory that the balloon device will consume. When the
crosvm main process detects that the system is low on memory, it
immediately increases the balloon size by the increment (unless it has
already reached the max). It then starts 2 timers: one to check for
low memory conditions again in 1 seconds (+ jitter) and another to
check if the system is no longer low on memory in 1 minute (+ jitter)
with a subsequent interval of 30 seconds (+ jitter).
Under persistent low memory conditions the balloon device will consume
the maximum memory after 16 seconds. Once there is enough available
memory the balloon size will shrink back down to 0 after at most 9
minutes.
BUG=chromium:866193
TEST=manual
Start 2 VMs and write out a large file (size > system RAM) in each.
Observe /sys/kernel/mm/chromeos-low_mem/available and see that the
available memory steadily decreases until it goes under the low memory
margin at which point the available memory bounces back up as crosvm
frees up pages.
CQ-DEPEND=CL:1152214
Change-Id: I2046729683aa081c9d7ed039d902ad11737c1d52
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1149155
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
This function will be used elsewhere in gpu_display.
TEST=None
BUG=None
Change-Id: I58b820511ea5a55a53ad640fdfe7c96d2dbdc73b
Reviewed-on: https://chromium-review.googlesource.com/1105481
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
We do not want to add dependencies on GCC. Switch to cc crate
instead of gcc to honor CC setting.
CQ-DEPEND=CL:1066462
BUG=chromium:814480
TEST=emerge-{eve,kevin} crosvm works.
Change-Id: I4e846b2080503e5617ed66e709f7af5263c98fba
Reviewed-on: https://chromium-review.googlesource.com/1066461
Commit-Ready: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The signature for this system call was wrong, but somehow managed to
work on x86_64. This should fix it to work on all architectures.
BUG=chromium:840048
TEST=build_test passes
TEST=virtio wayland works on ARM
Change-Id: I295548357f688be4772e65991fb65178ead3b1e8
Reviewed-on: https://chromium-review.googlesource.com/1050915
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This commit addresses a number of issues with the way in which the
SIGRTMIN() + 0 signal is used to kick VCPU threads. It
1. Moves the registration of the signal handler to the main thread.
There's no need to register the handler once for each VCPU as
there's one handler per process, rather than one per thread.
2. Ensures expect is not called in the VCPU thread before
start_barrier.wait() is called. In the current code,
failure to register the signal handler causes crosvm to hang
rather than to exit as the VCPU thread panics before calling
start_barrier.wait(). The main thread then blocks forever while
waiting on the barrier.
3. Uses the KVM_SET_SIGNAL_MASK ioctl to remove a race condition in
the current code. In the current code, a SIGRTMIN() + 0 signal,
received during a vm exit, would be consumed before the next call
to KVM_RUN, which would execute as normal and not be interrupted.
This could delay the VM from stopping when requested to do so.
Note that the new code doesn't unblock all signals during
the call to KVM_RUN. It only unblocks SIGRTMIN() + 0. This is
important as SIGCHILD is blocked at the start of run_config, and
we probably don't want this unblocked periodically in each of the
VCPU threads.
TEST=run crosvm and stop it in both single and multi-process mode.
BUG=none
Signed-off-by: Mark Ryan <mark.d.ryan@intel.com>
Change-Id: Ibda7d6220482aa11b2f5feee410d1d2b67a7e774
Reviewed-on: https://chromium-review.googlesource.com/1019443
Commit-Ready: Mark D Ryan <mark.d.ryan@intel.com>
Tested-by: Mark D Ryan <mark.d.ryan@intel.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The PollContext::wait returns Error on EINTR, which often happens during
suspend/resume cycles. Because this Error is transient, this should be
handled internally with a retry until a fatal error is encountered.
BUG=chromium:834558
TEST=run crosvm, suspend, resume, observe crosvm still running
Change-Id: I75469e261ddf28f025a3b3b93612538ccf1230b9
Reviewed-on: https://chromium-review.googlesource.com/1018527
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Now that there are no users of that interface, we should remove it.
TEST=./build_test
BUG=chromium:816692
Change-Id: Ifdbde22984f557b945e49559ba47076e99db923b
Reviewed-on: https://chromium-review.googlesource.com/1000103
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Making a copy of PollEvents is useful to drop the PollEvents structure
which borrows from a PollContext. Even though immutably borrowing from a
PollContext does not prevent any operations on a PollContext, it does
prevent mutable method calls on any structure that owns PollContext.
TEST=None
BUG=chromium:816692
Change-Id: I9527fd5c122a703933deb973ad549b792226e4c6
Reviewed-on: https://chromium-review.googlesource.com/1000101
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The mmaps made through the sys_util API are usually for guest memory or
other large shared memory chunks that will pollute the file system with
huge dumps on crash. By using MADV_DONTDUMP, we save the file system
from storing these useless data segments when crosvm crashes.
TEST=./build_test
BUG=None
Change-Id: I2041523648cd7c150bbdbfceef589f42d3f9c2b9
Reviewed-on: https://chromium-review.googlesource.com/890279
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Files are Pollable because they have an FD. Whether this makes sense for
any specific `File` is not enforced, but it will never be unsafe or
undefined when used with Poller.
BUG=chromium:793688
TEST=None
Change-Id: I2ce7ffd1b408bcee5ffbb3738d26339aa0c466e0
Reviewed-on: https://chromium-review.googlesource.com/985617
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
If POLLHUP is filtered out of the returned tokens, the caller of
Poller::poll will likely just put the same (token, fd) in the next call
to poll which will return instantly. This degrades into a busy poll loop
without the chance for the caller to change the poll list.
Instead, this change changes the filter to return tokens on POLLHUP so
that the caller will hopefully notice the FD associated with the token
has been hungup and will close it.
BUG=chromium:816692
TEST=None
Change-Id: Ie36d8a647a5fd7faabfd57a562205f75c77991e7
Reviewed-on: https://chromium-review.googlesource.com/985616
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The only instance of libstd getting file flags is the debug formatter
for `File` which would be hacky to depend on. This change adds a type
and method to directly get open file flags.
TEST=cargo test -p sys_util
BUG=chromium:793688
Change-Id: I9fe411d8cb45d2993e2334ffe41f2eb6ec48de70
Reviewed-on: https://chromium-review.googlesource.com/985615
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This is useful to get the total size of memory without having to write
something that iterates over the regions explicitly.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: Iac9a341b4c41d6462cf731f6267b92a0169578e4
Reviewed-on: https://chromium-review.googlesource.com/977565
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Calculate the number of bits necessary to represent the enum variant
using the next_power_of_two() and trailing_zeros() functions from the
primitive usize type.
Also add a test to ensure that the returned value is correct when there
is only one variant in the enum.
BUG=none
TEST=unit tests
Change-Id: Ibd15efd4f06e17a74489fee04ff19aca0dde68b2
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/959624
Reviewed-by: Zach Reizner <zachr@chromium.org>
This change simplifies plugin processing by removing the awkward
run_until_started loop. This also switches to use PollContext instead
of the Poller/Pollable interface, which required reallocating a Vec
every loop to satisfy the borrow checker.
TEST=cargo test --features plugin
BUG=chromium:816692
Change-Id: Iedf26a32840a9a038205c4be8d1adb2f1b565a5c
Reviewed-on: https://chromium-review.googlesource.com/938653
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Using an enum implementing PollToken is the recommended way to use
PollContext, but writing the trait impls for each enum is mechanical yet
error prone. This is a perfect candidate for a custom derive, which
automates away the process using a simple derive attribute on an enum.
BUG=chromium:816692
TEST=cargo test -p sys_util
Change-Id: If21d0f94f9af4b4f6cef1f24c78fc36b50471053
Reviewed-on: https://chromium-review.googlesource.com/940865
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
A common cause of silent 100% CPU usage on otherwise idle VMs is because
some poll loop is waiting on sockets that were hung up on. An unrelated
issue is that using the Poller interface requires dynamic allocation on
every poll call for dynamically sized poll lists.
The PollContext struct detects and warns about the first problem at runtime
and solves the latter problem.
TEST=cargo test -p sys_util
BUG=chromium:816692
Change-Id: I42a9c961db07191d25bcba77c5136f5729400ec9
Reviewed-on: https://chromium-review.googlesource.com/933870
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
On Linux, signal handlers installed with signal() will restart
interrupted system calls. When we moved to using sigaction() we forgot
to specify SA_RESTART and so we started experiencing returns from read
write system calls with EINTR, which throws off some of the code.
Instead of sprinkling "handle_eintr" everywhere, let's restore the old
behavior.
TEST=cargo test --features plugin; cargo test -p sys_util
BUG=chromium:800626
Change-Id: I24c23069ad4c9e7be8c484ee4c57f67451a2944d
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/944848
Reviewed-by: Zach Reizner <zachr@chromium.org>
I ran into an issue on ARM where ppoll() was returning EINVAL and it
was becuase our timespec value sent to ppoll contained a negative
value for tv_sec. We need to use the correct type when determining
the max value.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: I7f8818e5f93e0327fd9facefb5032f7c5fb00ea0
Reviewed-on: https://chromium-review.googlesource.com/945111
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
System functions have 2 ways of signalling errors, either via returning
-1 as result, and setting errno, or directly returning error code, and
we can not distinguish automatically between the 2 options when using
InterruptibleResult trait for i32 values.
Let's remove this trait for i32 and create 2 explicit macros:
handle_eintr_rc and handle_eintr_errno.
TEST=cargo test --features plugin; cargo test -p sys_util
BUG=None
Change-Id: I1dc8e3c023e7bf7875ac3536703eb71fa3206b7b
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/940612
Reviewed-by: Zach Reizner <zachr@chromium.org>
System error codes are positive, we should not try to use the negative
(kernel) form when working with it.
TEST=cargo test --features plugin; cargo test -p sys_util
BUG=None
Change-Id: I8dea773e6148d1814ca0ea5019d5fb7824dc80ac
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/940611
Reviewed-by: Zach Reizner <zachr@chromium.org>
scm_sendmsg() and scm_recvmsg() return negative errors derived from
errnos that are normally positive. When constructing errno::Error from
these error codes we should convert them back into positive values for
error codes to make proper sense.
TEST=cargo test --features plugin; cargo test -p sys_util
BUG=None
Change-Id: Ibf9065b72602e43cb6badd06f85044329d714276
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/940562
Reviewed-by: Zach Reizner <zachr@chromium.org>
This is helpful in passing up low-level errors from system calls.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: Ic2d8a23240a1449ac78877d37a074fd97a29a065
Reviewed-on: https://chromium-review.googlesource.com/933375
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
This implements the error trait so we can get more useful error
information back on failures.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: Ia131b1eb14d24709c10f2ba752a962e822134a42
Reviewed-on: https://chromium-review.googlesource.com/938312
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
We need this ioctl to implement race-free support for kicking/pausing VCPUs.
TEST=cargo test --features plugin; cargo test -p kvm; ./build_test
BUG=chromium:800626
Change-Id: I5dcff54f7eb34568a8d8503e0dde86b6a36ac693
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/932443
Reviewed-by: Zach Reizner <zachr@chromium.org>
