From fuse/dev.c in Linux kernel[1], max_write should not include the
headers. Without this fix, the buffer returned by the FUSE device comes
with a header that fails this check.
[1] https://elixir.bootlin.com/linux/v5.11-rc7/source/fs/fuse/dev.c#L1220
BUG=chromium:1176310
TEST=large write succeeds after applying this fix
Change-Id: I321c27a0ca005de6a021bdf044b7d859b57f1cfa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2685219
Tested-by: Victor Hsieh <victorhsieh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Victor Hsieh <victorhsieh@chromium.org>
Allow the caller of config_register_write to determine whether a given
write to PCI configuration space has enabled or disabled the memory or
I/O bits in the command register. This will be used as a signal to
insert or remove a PCI device to/from the corresponding bus.
BUG=b:174705596
TEST=cargo test -p devices
TEST=Manual test with full PCI BAR remapping patch set
Change-Id: I7a3484bd5143d25756c6fdc9f3a8f684db7db8cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2388964
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This adds support for battery charge, voltage, battery charge counter
in power_monitor and populates these fields from powerd data.
BUG=b:162479956
TEST=Compare voltage_now, charge_full, charge_now/charge_counter,
current_now fields in sysfs on host and in ARCVM
TEST=CTS tests android.cts.statsd.atom.HostAtomTests#testBatteryVoltage,
android.cts.statsd.atom.HostAtomTests#testFullBatteryCapacity
and android.cts.statsd.atom.HostAtomTests#testRemainingBatteryCapacity
pass in ARCVM
Change-Id: I3f93f499fa7d00cc5a0a2b69e7cfbcd233a2983a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2681212
Tested-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alex Lau <alexlau@chromium.org>
Use resources allocator to assign or reserve PCI device address.
For pass-through devices it will enable 1:1 mapping to the host BDF.
Transition to address_allocator for pci address and irq allocations.
BUG=None
TEST=build_test && tast run vm.*
Change-Id: I854da9645a305b7b24acb3dd6d851c3486ed23f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2210848
Tested-by: Tomasz Jeznach <tjeznach@chromium.org>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Fixes some nits that cause kokoro builds to fail and updates
the Kokoro configs to match the new Kokoro-side configs
submitted in cl/355894530.
With this CL Kokoro v2 should be passing and can be enabled as
a presubmit.
BUG=b:179289824
TEST=Kokoro passes
Change-Id: I8c9259407bf1eb932b05376b35cb88d2e7d6058c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2678792
Tested-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Should fix the following error:
---- rutabaga_gralloc::gralloc::tests::create_render_target stdout ----
thread 'main' panicked at 'called `Result::unwrap()` on an `Err`
value: Unsupported', rutabaga_gfx/src/rutabaga_gralloc/gralloc.rs:314:64
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
BUG=b:173630595
TEST=cargo test locally
Change-Id: Ieb24166f3975d4d7c99c08a3d0824ee64668c93e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2675231
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Adds the crosvm-side infrastructure to build and test
in kokoro.
There is a build script for testing on x86, aarch64
and a separte script for analysis (clippy, fmt).
These will run in parallel on Kokoro. To test the
scripts locally, a simulate script is provided.
Runtime on my workstation:
- aarch64: 10m
- x86: 2:30m
- analysis: 1:40m
BUG=b:177951955
TEST=./ci/kokoro/simulate_all
Change-Id: I2f666ec768e6c3391a258dc7f0cbd999ad9b2fb1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2654413
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The VM allows both the x86 and aarch64 builders to run tests which
require access to kernel devices that docker would prevent us
from accessing.
The VM is automatically started in the endpoint script, and the
environment is set up to execute `cargo test` binaries inside the VM.
This allows for convenient interactive usage.
The VM is also integrated into the run_tests scripts, executing tests
that do not require special privileges first, while the VM is still
booting up, then execuing the remaining tests in the VM.
BUG=b:177228167,b:177951276
TEST=These test calls pass:
./ci/builder --vm ./run_tests
./ci/aarch64_builder --vm ./run_tests
./run_tests
Change-Id: I20bf2cd848e944d411b97f1f8356279e312d8583
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2642766
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
When building without the "audio" feature, an import of virtio::snd in
pci_device failed to compile; wrap it in a feature check to fix this.
This fixes the crosvm fuzzer build.
BUG=chromium:1174254
TEST=cargo build --no-default-features
TEST=build crosvm with amd64-generic asan profile
Change-Id: Iecd549c313d6210ee90e9e405c02a9e7581e1141
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2674260
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
rutabaga_gralloc is a cross-platform, Rust-based buffer
manager.
The rationale for this change is:
1) For the {cross-domain, wayland} context type, we need to
have a good story for the crucial "wl-dmabuf" feature. As
minigbm has been thoroughly tested on ChromeOS and currently
powers the "wl-dmabuf" feature, it only makes sense for us to
have a path to minigbm for the cross-domain prototype. This
will be used by Sommelier.
2) While minigbm allocation works well on Chromebooks, it is
not sufficient for cross-platform purposes. For their Virtual
Graphics Interface (VGI) initiative, Android graphics
virtualization experts have expressed their desire for a Vulkan
based allocator. This will to go alongside cros_gralloc in
minigbm, which is considered by many to be the ""world's
premiere gralloc implementation".
3) Android graphics virtualization experts have expressed their
desire for vkMapMemory(..) to be used when crosvm is in
multi-process mode. Currently, only dma-buf mmap() is supported
for zero-copy blobs in multi-process mode. dma-buf mmap() is not
guaranteed to work on Nvidia (a "must have" for Cuttlefish) or
any other driver for that matter (we *make* it work for ChromeOS).
Possibly only solution: vkMapMemory ;-)
With these goals in mind, here's a summary of the revelant changes:
* Renamed the {gpu_allocator.rs, GpuMemoryAllocator trait} to be
{gralloc.rs, Gralloc trait}.
* Moved all GPU allocation out of the resources crate and into
the rutabaga_gfx crate. This will allow the resources crate to
be focused on managing resources for virtual machines.
* Moved the gpu_buffer crate into the gralloc module in the
rutabaga_gfx crate. The same functionality is now under
"minigbm.rs", "minigbm_bindings.rs" and "rendernode.rs"
* Added an optional dependency on vulkano.rs. vulkano.rs is a safe
Rust wrapper around the Vulkan api [a]. It's emphasis on type
safety makes a good fit for crosvm, though there are other high
quality crates out there (gfx-rs, ash.rs). Though development
has slowed down, it should satisfy goals (2) and (3) quite easily.
* Added a system_gralloc implementation based on memfd. This can be
used when minigbm or Vulkano features are not used, to replicate the
highly useful "wl-shm" feature in Sommelier. Astute observers will
note this can also enable seamless Wayland windowing without GPU
features for Android too. Some minor changes to the base crate were
needed.
* Cut down on the amount of DrmFormats to the subset needed by
Sommelier and cros_gralloc.
* Moved checked arithmetic into it's own file.
* Internally renamed to "wl-dmabuf" feature to be the "minigbm"
feature. This is because "wl-dmabuf" has a dependency on minigbm.
* Small rutabaga_gfx cleanups
[a] https://github.com/vulkano-rs/vulkano/blob/master/DESIGN.md
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=run sommelier with "wl-dmabuf" and "wl-shm"
Change-Id: I693a39cef64cd98e56d843d3c60caa7983d4d6e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626487
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Offset right now means the offset from base address that the
device was accessed at. And address is the absolute address
of the device's access in its address space. The port 0x61 and
0x64 is the absolute port number.
BUG=None
TEST=boot VM and run reboot command
Change-Id: I51ee90e51b559254cf76f2bec4d174294961fe1c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2648858
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Alistair Delva <adelva@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Alistair Delva <adelva@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
The arcvm guest has been observed to fail early in boot with a low
probability; the root cause seems to be a missing interrupt from the
virtio-block device causing the guest to wait forever for a notification
that does not happen.
In testing, it seems that ignoring the VIRTQ_AVAIL_F_NO_INTERRUPT flag
set by the guest avoids the issue; possibly there is a race in the
publishing of used descriptors versus the checking of this flag, but I
was not able to find a definitive solution.
Ignoring the flag means that we may occasionally trigger an interrupt
when the guest has indicated that one is not necessary; this is, at
worst, a slight performance degradation, not a correctness issue, since
the guest kernel will ignore spurious interrupts.
BUG=b:172975852
TEST=Restart arcvm in a loop without failures 1000+ iterations
Change-Id: I4c91ccc5dadc03dde43008ff20fae1c4592e19da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2648009
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This reverts commit 890ae4cdb8.
Reason for revert: breaks arc.Boot.vm on kukui-arc-r
Original change's description:
> Relocate FDT to beginning of RAM
>
> This change serves two purposes. The FDT needs to be in a location
> accessible by 32 bit devices. Secondly the FDT's location was dependent
> on the amount of RAM allocated to the guest prior to this change which
> made passing it's location to the BIOS challenging.
>
> By moving the FDT to a fixed location within the 32 bit accesible memory
> boundary, these problems have been fixed.
>
> BUG=b:177926450
> TEST=local boot of android virtual device on ARM host
> Change-Id: I89e481f66ddc8ffcf0e86f00fbfa92d407c48736
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2641126
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Tested-by: Ram Muthiah <rammuthiah@google.com>
> Commit-Queue: Ram Muthiah <rammuthiah@google.com>
Bug: b:177926450
Bug: b:178427080
Change-Id: Iba629542d024fff84721ff434655c0c322020db3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2656215
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Ryo Hashimoto <hashimoto@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Ryo Hashimoto <hashimoto@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
These will eventually be used when the virtio-snd device is
implemented as well as by the VioS audio backend.
BUG=b/174713663
Change-Id: Id9fe1527a128df0059805076c01e20ddb1ad2b72
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574812
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Closing the uring fd should release the resources borrowed by the kernel
so there's no reason to call io_uring_enter to drive any pending IO to
completion. Doing so may end up blocking the thread indefinitely.
Instead just make sure that the URingContext is dropped before anything
else. Rust's drop order guarantees that struct fields are dropped in
the order of declaration so this just means putting it first.
Also, since the RawExecutor is wrapped in an Arc it may end up being
dropped from a different thread than the one that called run() or
run_until(). We know there are no other references so just clear the
cached thread_id so that we don't panic in the drop impl. We don't
currently have any users that want to run the executor concurrently on
multiple threads so we'll just punt that problem until we actually need
to deal with it.
BUG=none
TEST=unit tests
Change-Id: Icf6a23fc433128dd00adbd56a715dbae24cd8ea2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643845
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
IORING_OP_NOP is a no-op that does no IO and can be used to measure the
performance of the io_uring subsystem or to wake up a thread currently
blocked inside an io_uring_enter syscall. Use it instead of keeping a
separate eventfd.
BUG=none
TEST=unit tests
Change-Id: I3b3e93c653e1db747c90456c1d93abb979c25d34
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643844
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Rather than requiring callers to wrap the entire UringContext in a big
lock, make UringContext Sync by internally using fine-grained locks:
* The submit queue is wrapped with a Mutex so that threads may still add
operations to the submit queue even when a thread is blocked
inside an io_uring_enter call.
* The completion queue internally uses a Mutex around the pending op
data and completed count so that two threads don't end up trying to
remove the same operation from the completed queue.
With this we can enable the await_uring_from_poll test. This test
uncovered missing wakeups in the case where a uring operation is added
from one thread while the main uring thread is blocked inside an
io_uring_enter syscall. To deal with this, we call submit() whenever the
pending operation is polled and not yet submitted.
BUG=none
TEST=unit tests
Change-Id: I4c7dec65c03b7b10014f4a84d2cd16fe8758ea72
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643842
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This is like future::task::ArcWake but uses Weak<T> instead of Arc<T>.
This prevents a circular reference where the RunnableQueue would hold an
active reference to the executor (via its waker) while the executor
owned the RunnableQueue, leading to memory leaks.
With this the executor should only be using weak references internally
and the only strong references should be in the public *Executor type.
Also fix the tests that were broken by this change.
BUG=none
TEST=unit tests
Change-Id: I3e9c007d533e154b2ad9d1e4d56a692f65da6aa0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643841
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
There are a lot of changes in this one but these are the high-level
points:
* Both executors now support non-fd futures and it's now possible to
start a poll operation on one thread and then await the result inside
a UringExecutor on another thread. The reverse doesn't work yet but
will once we make UringContext sync.
* A few layers of indirection have been removed so hopefully both the
implementation and the interface are simpler.
* The thread local magic is gone in favor of directly calling methods on
an executor. Executor handles can be cheaply cloned to make this
easier.
* Heap allocations are limited to the spawn and spawn_local methods so
it's possible to completely avoid heap allocations if callers only use
the run_until method.
* The IoSource, Executor, FutureList traits are gone.
BUG=none
TEST=unit tests
Cq-Depend: chromium:2629068
Change-Id: I86053007929c36da66f3b2499cdefce0b5e9a180
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2571401
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This change serves two purposes. The FDT needs to be in a location
accessible by 32 bit devices. Secondly the FDT's location was dependent
on the amount of RAM allocated to the guest prior to this change which
made passing it's location to the BIOS challenging.
By moving the FDT to a fixed location within the 32 bit accesible memory
boundary, these problems have been fixed.
BUG=b:177926450
TEST=local boot of android virtual device on ARM host
Change-Id: I89e481f66ddc8ffcf0e86f00fbfa92d407c48736
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2641126
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Ram Muthiah <rammuthiah@google.com>
Commit-Queue: Ram Muthiah <rammuthiah@google.com>
A few things happened:
- A recent minigbm change broke compilation for debian, so
I am pinning the commit SHA for the Dockerfile.
- Newer rust versions come with new clippy errors, which I will
have to look at in a separate change. For now I am pinning our
rust version.
- Some repos have transitioned to a main branch. Fixed our uprev
script to handle those.
- Renamed SYSROOT so we won't confuse pkg-config.
Now Kokoro is finally happy again!
BUG=None
TEST=wrapped_smoke_tests
Change-Id: I76294abe35fd84b305124158b3942a321651982d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643779
Tested-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The ./run_tests script will select which tests to run on the host.
Unfortunately a lot of our tests require dependencies or access
to certain kernel devices. We cannot run all tests on all hosts.
The test runner works with the CI builders:
To run all x86 tests:
./ci/builder ./run_tests --all
To run tests on aarch64:
./ci/aarch64_builder ./run_tests --all
Or to just run tests that can be run on a standard debian buster
system without obscure chromeos dependencies:
./run_tests
Eventually, the test runner should run tests via the VM of the
aarch64_builder, currently only those tests that can be run with
user-space emulation are executed.
Currently some tests remain disabled in the runner, as they do not
pass in the CI builders yet. These will be enabled as the builders
are set up to allow for them to be run.
BUG=b:173833661
TEST=Ran the above commands.
Change-Id: Id69027793348f4d3f20adf5333d8bdfff1aa9c8b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2633889
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
This USB ioctl is used in usb_util::Device::clear_halt(), but it was not
allowed in the seccomp policy.
BUG=chromium:1167286
TEST=Attach Keyspan USA-19H USB serial adapter to Crostini
Change-Id: I625cde121a0a248046e476eecd732a98530811dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2633824
Reviewed-by: Matthew Blecker <matthewb@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Matthew Blecker <matthewb@chromium.org>
Commit-Queue: Matthew Blecker <matthewb@chromium.org>
Annotate the THREAD_SYNC flags with allow statements so that clippy does
not complain about them.
BUG=None
TEST=bin/clippy
Change-Id: I9d9d5d5b2a5f51e3ce49c36dd7528ad677aeb30e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2638139
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This CL expands the existing boot.rs test to not just boot a kernel
but also provide a debian-based rootfs and a special init binary
that is used to communicate between test code and the guest VM.
The delegate binary listens for commands on /dev/ttyS1 and returns
the stdout of the executed command.
This allows the test code to setup pipes for the serial device to
issue commands in the client and receive the command output, which
provides a good foundation for tests of basic functionality without
the need to pass test binary code into the guest.
The integration tests will pull a prebuilt kernel and rootfs image
from cloud storage unless local files are specified via ENV variables.
The integration_tests/guest_under_test directory contains the files
needed to build and upload those prebuilts.
BUG=b:172926609
TEST=This is a test.
Cq-Depend: chromium:2551073
Change-Id: Iffb88a146a13d1b6ed7250df1b487bd87a5599d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2536831
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Auto-Submit: Dennis Kempin <denniskempin@google.com>
This CL adds the foundation for running tests consistently
in Kokoro and locally, for both x86 and aarch64.
The crosvm_builder is similar to the original image from
docker/crosvm.Dockerfile.
The main difference is that ChromeOS dependencies are not
compiled into the container, but built at runtime.
The crosvm_aarch64_builder installs the build enviornment
to cross-compile crosvm for aarch64. The tests are run
with user-space emulation using qemu-aarch64-static.
See ci/README.md for instructions on how to use these
builders.
Tests on aarch64 cannot all be run using user-space
emulation. We will need a VM to pass all smoke tests,
this work is tracked in b/177228167.
BUG=b:177133814
TEST=Tested by running
./ci/builder bin/smoke_test
./ci/builder cargo test
./ci/aarch64_builder cargo build
./ci/aarch64_builder cargo test -p tempfile
Change-Id: Iffffcf48894787dd72fff894af351fdaced0b429
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2621994
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Make it stand out in logs and easier to `grep` for the message in
automated scripts such as tests.
BUG=b:152259067
TEST=Introduce failure in crosvm and try booting ARCVM
Change-Id: I0ca76f8a68eb650c95e072224d0a9d019696ac6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2413914
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
This is ABI-compatible with iovec and comes with Send + Sync impls,
which iovec does not have.
BUG=none
TEST=unit tests
Change-Id: Ic5831f557933b1d0dc823b1f6ba991ffe57baf2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2571149
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
This should hopefully make it easier to distinguish it from
std::io::IoSliceMut.
BUG=none
TEST=unit tests
Change-Id: I0746239c23e014cdccac62f1b89ec78f4008d22c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2627238
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Move the RutabagaIovec representing the display framebuffer out of
match's Some() condition so that it outlives the call to the
underlying renderer.
BUG=b:173630595
TEST=launch_cvd --gpu_mode=gfxstream
Change-Id: I86b2ddd0de0551bf0fbbbfebf811c39d7581f3cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2627646
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
The fuzz_server interface was updated to require a Mapper; however,
fs_server fuzzer was not updated to provide one, and it does not seem
necessary since the Mapper calls don't affect control flow in the
server. Instead, just provide a no-op Mapper inside fuzz_server.
Fixes fs_server_fuzzer build.
BUG=chromium:1166742
TEST=FEATURES=test emerge-amd64-generic crosvm # --profile=asan
Change-Id: I6f2d2c7156056976a2e5dd1d7b5a29a231608150
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2629970
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This seems to be faster than using UC and brings perf close to or
on par with goldfish address space blobs.
BUG=b:177241396
Change-Id: I8198ac0a0510388e79753cdb22007f97dcb3568b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2621997
Commit-Queue: Lingfeng Yang <lfy@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Lingfeng Yang <lfy@google.com>
