Adds `crosvm gpu <>` commands which allows for interactively
adding/listing/removing virtio-gpu displays/scanouts.
Also updates the virtio gpu device to use a Map<u32, Scanout>
instead of a Vec<Scanout> and always report the maximum number
of displays (16) with enabled/disabled. This helps handle the
case of removing a display that is not the last display number.
BUG=b:163864461
TEST=cargo build
TEST=cargo build (with gpu feature disabled)
TEST=Android build
TEST=launch Cuttlefish
TEST=crosvm gpu list-displays <socket>
TEST=crosvm gpu add-displays
--gpu-display=width=900,height=600
--gpu-display=width=600,height=480
<socket>
TEST=crosvm gpu list-displays <socket>
TEST=crosvm gpu remove-displays
--display-id=1
<socket>
Change-Id: I7530498897eb4e84199eaeb3d66df006df62817f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911102
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
FromStr trait is manually implemented for ExecutorKind, but
serd_keyvalue should be preferred. This commits refactors ExecutorKind
so that derives serd_keyvalue.
BUG=None
TEST=`crosvm --async-executor (epoll|uring) run ...` works
TEST=test passes on linux and windows
Change-Id: I5aafb6704c20a17120b30c290e1a4069dff9e5ce
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924880
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Takaya Saeki <takayas@chromium.org>
Fuzzer targets can be ran with
cargo +nightly fuzz run --fuzz-dir crosvm-fuzz --features
upstream-fuzz <target>
This should enable us to move fuzzing to anywhere including
ClusterFuzz while maintain compatibility with cros infra.
TEST=`cargo fuzz` won't crash in first 30s,
`USE="asan fuzzer" emerge-hatch crosvm` builds,
`/build/hatch/usr/libexec/fuzzers/crosvm_qcow_fuzzer` won't
crash in first 30s
FIXED=b:245007212
BUG=b:244631591
Change-Id: I4b262ee1a6a90247dea96347c55a3849af793bec
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3905095
Auto-Submit: Zihan Chen <zihanchen@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
We were already accepting AvFrame for swscale inputs, but for the output
a different SwConverterTarget trait was being used.
The old interface had a few issues:
- The use of memory mapping traits, putting a dependency on crosvm/base
- Insufficient metadata, not being able to represent custom padding on
the stride or non-contiguous plane layouts
- Inconsistency between input and output types
In this patch, we:
1. Introduce a AvFrame-based API to replace the old SwConverter API.
2. Add a TryAsAvFrameExt extension trait inside devices/ to convert
virtio handles to AvFrames.
(This is placed inside devices to avoid ffmpeg depending on base.)
3. Add a new wrapper type, MemoryMappingAvBufferSource, that wraps a
MemoryMappingArena and implements AvBufferSource for it. This was
technically not sound, but it's a low-risk attack vector that we
implicitly allowed before. The patch doesn't change the behavior; it
just makes this assumption more explicit.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: Id15e19b7d2452d1bc722a65f941c2c9150876205
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3889245
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Adds a script that copies the bindings we need upstream. We cannot
use the original repository, as it's part of the large platform2 git
repository, and the original build.rs depends on ChromeOS tooling to
generate these bindings.
So instead, this change adds a script that can be called from a
chromiumos checkout of crosvm to update the upstream bindings.
This allows us to enable certain features that talk to ChromeOS
dbus services. They won't be functional upstream, but at least we
can compile and test the code.
To make things more consistent, we no longer replace the crate
with the ChromeOS version when building for ChromeOS.
BUG=b:244618505
TEST=presubmit
Change-Id: I504cbf6d12b0cb50d9935f5e49b7fa72b692d45c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3919814
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
BUG: b:244618109
TEST: Presubmit and built with the feature on windows and linux.
Change-Id: Idf9ae87243eb0a7c7b9a6ff525406f1430b49c20
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3916339
Commit-Queue: Vikram Auradkar <auradkar@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Stub the required parts of libcras so that upstream builds with
audio_cras feature
BUG=b:244618503
TEST=cargo build --features audio_cras
Change-Id: I21eb3bcb9a61990740b1419f124401878619481e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911099
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Vineeth Pillai <vineethrp@google.com>
This is to keep consistency with Windows downstream code.
The conversion from ProcessType to EmulatorProcessType is moved to
the metrics crate as it is only used for generating metrics.
BUG=b:213146388
TEST=presubmit
Change-Id: Ia62f76835a1f162dd8bbc9e53fd671968c368473
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3908370
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
On Windows, we have to create a GUI thread that creates the window and
retrieves window messages from the thread-specific message queue created
by the system. All host events, such as window resizing and mouse and
keyboard events, are sent in the form of window messages. Hence, we
created these structs/traits to model it:
- `Window`: Owns the handle of one window, and provides helper functions
for operating on this window.
- `HandleWindowMessage`: A trait implemented by the struct that
processes host events. In our case, that is the surface.
- `WindowMessageProcessor`: Holds one `Window` object and one
`HandleWindowMessage` trait object. We only support one window for
now. Once we support multi-windowing, there will be multiple
processors.
- `WindowMessageDispatcher`: A singleton, responsible for dispatching
messages retrieved from the message queue to the targeted processor.
- `WindowProcedureThread`: Wraps the GUI thread, retrieves messages from
the message queue and forwards them to the dispatcher. It also
provides helper functions for other threads to talk to the GUI thread.
- `MessageRelayThread`: Relays service messages to the GUI thread.
Main difference from other platforms: event devices are imported to the
GUI thread, since all host events are processed there.
BUG=b:213150276
TEST=presubmit
Change-Id: I0aabf6adf8a9ff4b24375e9c7df7625b6f761c7a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3834009
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Brings up the master request handler on Windows. To stay within the
existing protocol, PackedTube was introduced, which is able to transmit
a Tube via a RawDescriptor.
BUG=b:221882601
TEST=presubmit & cargo test & tested downstream
Change-Id: Ibd4c2f55c42738392beed5b15b8d445e47890627
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3856828
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Idan Raiter <idanr@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Seccomp policy files will now pre-compile to bpf bytecode for
target architecture and embedded in the crosvm binary when not
built for chrome os.
When minijail is not checked out in crosvm tree as a submodule,
MINIJAIL_DIR environment variable needs to be specified for the
policy compiler to run.
Integration tests are now sandbox enabled for better coverage.
TEST=all tests passed, vm runs fine with sandbox on and no separate
policy files present. cros deploy & crostini still works.
BUG=b:235858187
FIXED=b:226975168
Change-Id: Ieaba4b3d7160ccb342a297ebc374894d19a8dc4d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3824062
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Zihan Chen <zihanchen@google.com>
Bump the versions of these crates as we're about to require support for
unavailable register values and AArch64. Do it in a separate commit to
ease future bisects.
BUG=b:222222882
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I0bfa3559d172faf2df6bcffdc77714830f442051
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785466
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
Remove target_arch-specific #[cfg]s where the underlying code is
architecture-agnostic.
Introduce a GdbOps trait for architectures to implement.
Make use of the generic gdbstub::arch::Arch trait where relevant.
Import base::Tube unconditionally in arch/src/sys/unix.rs.
Expand crate::gdb::* in vm_control/src/lib.rs for clarity.
Keep target_arch checks in x86-specific code to exclude 32-bit builds as
those don't seem to provide GDB support.
BUG=b:222222882
BUG=chromium:1141812
TEST=tools/dev_container ./tools/run_tests
Change-Id: I3f5ceeeb9031bee222ecd388dddb815e256748e8
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3785464
Tested-by: Pierre-Clément Tosi <ptosi@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Pierre-Clément Tosi <ptosi@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
As a stepping stone toward fully asynchronous disk formats, add a
wrapper that takes a regular synchronous DiskFile and provides the
async disk API.
BUG=b:219595052
TEST=cargo build --features=composite-disk
Change-Id: Id785ad7ff69ae869a8a9007134fdb4fe7f3be4ba
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3824066
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Use the nom crate for parsing. This will arguably be both simpler to
read and more reliable than our current ad-hoc parser.
Add a few extra tests to enforce the new rules that the new parser is
supposed to enforce.
BUG=b:218223240
TEST=cargo test -p serde_keyvalues -p crosvm
TEST=ARCVM starts successfully.
Change-Id: I4ea188ffe8aee872071c900793c50127855403ec
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822428
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The first version of audio_streams_conformance_test.
It is used to test if the implementation of
audio_streams::AsyncPlaybackBufferStream is correct.
This version only supports the playback test of NoopStream.
It prints the following information for NoopStream.
==
Playback Source: NoopStream
Channels: 2
Format: S16LE
Sample rate: 48000 frames/s
Buffer size: 240 frames
Iterations: 10
Cold start latency: 3.89µs
Records count: 10
[Step] min: 4.94 ms, max: 5.15 ms, average: 5.01 ms,
standard deviation: 0.06 ms.
[Linear Regression] rate: 47916.19 frames/s, standard error: 2.0
BUG=b:238038707
TEST=cargo run
Change-Id: Ifca7dfd35473ffd75856a27e2c6aa1555eba7576
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3805090
Tested-by: Judy Hsiao <judyhsiao@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
Auto-Submit: Judy Hsiao <judyhsiao@google.com>
We originally removed it because we had frequent merge conflicts
and all downstream projects were doing their own pinning already.
We also had CI issues because ChromeOS changes could trigger
Cargo.lock changes in crosvm back then.
The new Cargo.lock format should ease the merge conflicts and we
no longer have issues with external changes triggering changes
in our Cargo.lock. So let's bring it back in.
This will allow us to judge the impact of changing third party
dependencies and gives us a chance to implement a special
review process.
BUG=b:240435583
TEST=CQ
Change-Id: Ie53e5616cc98d7e50a84f3c0a91902dd539f2520
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3795655
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
The Cargo.lock file has been source of much annoyance and does not
really serve it's purpose in crosvm anyway. Both Android and ChromeOS
builds will not use Cargo.lock files but use their own infra to pin
dependencies to fixed versions.
Cargo.lock files are only used for development builds, but can cause
frequent merge issues, especially once our hacky 'setup_cros_cargo.sh'
script is involed.
Since we are planning to migrate towards bazel in the not-so-far future,
the easiest short term plan is to just remove Cargo.lock from version
control and deal with potential discrepancies in development builds.
BUG=None
TEST=None
Change-Id: I23736a61a4cc8131888d5ee2c19793066267f608
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3140584
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Use the crates.io implementation of tempfile instead of our own version.
Our reimplementation is kept in the tree for now in case of dependencies
outside of the crosvm tree; it can be removed later once those are fully
switched over to the crates.io implementation.
BUG=b:199204746
TEST=emerge-hatch crosvm
Change-Id: I07d3404239302ab9a17f4ddc82a9479b256e4eb4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3209839
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
We no longer need to build dependencies from source and provide them
via pkg-config, this simplifies much of our builder container setup.
As debian bullseye got promoted to stable, we can now also simplify
further by just using bullseye stable instead of mixing stable and
testing packages.
BUG=b:181359683
TEST=./test_all
Change-Id: I2ce61992d5cfe6eb5dc3f0ec61920dcc5455ca40
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3141772
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Both libraries have previously been built as part of
ci/build_environment/Makefile. This CL moves that behavior into the
build.rs file of rutabaga_gfx.
This is the last third party dependency that we need to build from
source, and allows us to build/test on the host machine instead of
requiring the builder container.
It also allows us to greatly simplify the builder containers, which
I will do in a follow-up CL as we also need to upgrade them to bullseye.
This CL uprevs virglrenderer to include:
https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/609
and minigbm to include: https://crrev.com/c/3141018
BUG=b:196059146
TEST=./test_all && ./run_tests --run-privileged
Change-Id: I4442ccc991d13a3fcfa224de50e916b3926f0cb4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3141771
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Enable with `--cras-snd`.
Verified:
Basic playback and capture
Missing features:
* Getting chmap/jack/stream info from CRAS. They are hardcoded for now.
* Jack connect/disconnect notifications from CRAS
* Reporting latency bytes to the driver. It is currently hardcoded to 0.
BUG=b:179757101
TEST=`aplay` and `arecord` inside a debian img with a 5.10 kernel built
with virtio snd support. Launched with crosvm on rammus/kukui/hatch
Change-Id: I240000a92418b75b3eb8dcd241ff320214b68739
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2777991
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Also removes the use of the hermetic flag in favor of not failing the
build if the submodule is not checked out.
This allows us to remove the tpm2 build from the build_environment
Makefile.
BUG=b:198293072
TEST=./test_all
Change-Id: Ide81e78efe0da3a1b64d4b8ef094a2e901f99ccf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3133623
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Replace the uses of read_struct() and read_struct_slice() with the
safe DataInit::from_reader() implementation.
BUG=b:197263364
TEST=./test_all
TEST=Boot bzImage kernel
TEST=Boot raw ELF kernel extracted with extract_vmlinux
Change-Id: I80f98243bfb58a7ae93e1686bc4d92b0cd485cda
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3108249
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
