This allows other languages to communicate directly with the control
socket without having to invoke `crosvm`
BUG=None
TEST=Ran ./run_tests
Change-Id: Icbf5905c41643b080bae3613b73a032467db1c4c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2772798
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kevin Hamacher <hamacher@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Now that there is more than one binary target, set the default-run to
the classic crosvm target, which is a superset of all the binary
targets.
TEST=cargo run (without --bin)
BUG=None
Change-Id: I199e8938d6a8bb69175391971bdf4f809bbe19e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2806225
Auto-Submit: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
With 'direct' feature enabled, crosvm-direct target
support for platform/host devices passthrough is added.
BUG=b:173824333
TEST=build with 'USE=crosvm-direct emerge-${BOARD} crosvm'
Change-Id: I52ded0604aff464175e6f3bfc9a813f7968547ff
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2798816
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Option to passthrough port and memory mapped IO and
enable direct host device access for the guest.
BUG=b:179801783
TEST=boot and validate access with iotools.
Change-Id: I93fcc93fecccab49fd9c08b5406bcc3533128147
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2733578
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
This is only needed by udmabuf driver, so key it on yet another
feature flag (called "udmabuf").
BUG=chromium:892806, b:173630595
TEST=cargo test
Change-Id: I434a5d1a35d009af0924440df4f72cc7cc9df0e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786288
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
I don't really remember why the fuzz crate needed to be a separate
workspace and doing it that way seems to break our fuzzer builds so just
move it into crosvm's workspace.
BUG=none
TEST=USE="asan fuzzer" emerge-amd64-generic crosvm
Cq-Depend: chromium:2777911
Change-Id: Ibb0e2de14189683ee5af501392594230996accc3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2772678
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@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>
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>
It's possible to compile the gpu device without virgl_renderer.
In fact, in many instances, this may be required.
This builds the gpu device default, but only with --gpu do I see
/dev/dri/renderN128, so this should be safe.
BUG=b:173630595
TEST=compile and run
Cq-Depend: chromium:2592111
Change-Id: I5fbf2de8a2f818a9ca2e5ac4a1a02c7797cff927
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2592089
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
rutabaga_gfx is a cross platform, Rust-based, Wayland and
Vulkan-centric Virtual Graphics Interface (VGI).
Apologies for the mega-change, but it was hard to do this piece
by piece.
The rationale for this change is:
1) Android graphics virtualization experts have been proposing
for a VGI for many months (years?). Their goal is to boot
Android anywhere, everywhere.
2) For the {wayland, cross-domain} context type prototype,
it's desirable to create a {wayland, camera} connection at the
appropriate time. Details can be found in the code, though the
RutabagaChannels have yet to be hooked up.
There's a high chance neither effort will work. As such,
rutabaga is just a prototype.
However, even (1) and (2) don't end up working, this
refactor/cleanup by itself makes a ton of sense.
Here's a summary of revelant changes:
* Removed auto-generated {p_defines, p_format, virgl_protocol}.
These files were added for tests when bringing up crosvm-gpu,
and AFAICT these tests are not run. There's actually now a
commit queue for virglrenderer changes and container boot tests
that provides excellent coverage.
* Removed command_buffer.rs. Used only for the previously
mentioned tests. It's quite nice, but couldn't determine the right
place to put it. Maybe data_model? But removed it in the interim.
* Removed {write_from_guest_memory, read_to_volatile}. The same
basic functionality has been moved into {transfer_write,
transfer_read} in Rutabaga.
* Removed VirtioResource, Virtio3DResource, Virtio2DResource,
and VirtioGfxStreamResource in favor of VirtioGpuResource and
RutabagaResource. This leads to less duplication and clearer
separation between external library functions and VMM functions.
* Moved display and hypervisor memory management functions to
virtio_gpu.rs. This is because external components do not interface
with this functionality, and there was a lot of duplication (for example
map/unmap blob).
* Added context management between gfxstream and virglrenderer.
* Added separate gfxstream and virglrenderer flags.
* Clearer naming.
* Added simple implementations for context init and multiple timelines.
These changes have no effect since all Google kernels don't pass the
revelant flags, but are useful for theoretical {wayland, cross-domain}
prototype.
* Unify RESOURCE_CREATE_3D and RESOURCE_CREATE_2D handling.
* Better error handling.
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=boot ARCVM
Change-Id: I240b0c134a3b562cbc65981837a41f6db7767c92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2522452
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
PowerMonitor trait objects can be used as a source of power supply data
and will be used by the goldfish battery. This CL includes a powerd backed
implementation of PowerMonitor available behind a feature flag which
receives updated data over D-Bus.
BUG=b:137890633
TEST=observe updated power data in ARCVM's /sys/class/power_supply at the end of this chain
Cq-Depend: chromium:2550102
Change-Id: Iacdc9bc7d11454d5b4f5d2639d19281174ad7e20
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2537349
Commit-Queue: Alex Lau <alexlau@chromium.org>
Tested-by: Alex Lau <alexlau@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Add a flag '--gdb <port>' to provide GDB remote protocol interface so
a developer can attach GDB to the guest kernel.
In this CL, we support read/write operations for registers and memories.
BUG=chromium:1141812
TEST=Attach gdb and see register values on workstation and intel DUT
Change-Id: Ia07763870d94e87867f6df43f039196aa703ee59
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2440221
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Enable ascii casefold support for the 9p server when requested on the
command line. Needed by arcvm.
BUG=b:162388795
TEST=`stat foo.txt` and `stat FoO.TXt` return identical results even
though only foo.txt exists
Cq-Depend: chromium:2498170
Change-Id: Icf507ac0d8413e7794fdd643296d507781897039
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2501545
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
This is very largely boilerplate, but changes some interfaces
to accept different parameters, esp using Descriptor.
BUG=b:162363783
TEST=./build_test
Change-Id: I81b513c0de9448c2de505fe5d3a61a29f4eccb78
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2342591
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
It doesn't make sense to have 2 versions of this crate as we end up
missing bug fixes like chromium:2324089. Use the version from platform2
as that's updated more regularly.
BUG=b:167166153
TEST=Start a vm with a virtio-9p device and verify that it still works
Cq-Depend: chromium:2404987
Change-Id: I54abd88f64d599b68974c09a393c18ec830ecd76
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2404516
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Calls to the kvm crate have been replaced by calls to hypervisor and
devices::irqchip. Plugin is unchanged and still KVM-specific.
x86 creates and configures vcpus on the vcpu thread instead of the main
thread.
Code that still depends on kvm or kvm_sys:
- crosvm_plugin, plugin, and protos use kvm and kvm_sys if built with
the plugin feature
- devices::VfioGroup does a kvm_sys ioctl
- devices::irqchip and hypervisor use kvm_sys. hypervisor uses
kvm::Cap and kvm::CpuId internally for now.
BUG=chromium:1077058
TEST=runs es2gears_wayland on kukui
TEST=runs evince on amd64-generic with kernel and split irqchip
TEST=build_test excluding tpm2
TEST=cargo check --features plugin
Change-Id: I0068e34da6a5ff0079b1237be1958933bf12ffe4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2307711
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Steven Richman <srichman@google.com>
For now, this crate simply re-exports all of sys_util, but it will
be updated to provide new interfaces when needed. This is the
first step to making crosvm not directly depend on sys_util, so
that we can make the interface changes we need without fear of
negatively affecting (i.e. completely breaking) other usages
within chromeos.
BUG=b:162363783
TEST=./build_test
Change-Id: I7d0aa3d8a1f66af1c7fee8fd649723ef17027150
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2325168
Tested-by: Michael Hoyle <mikehoyle@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Move GuestAddress and GuestMemory to a new crate for VM memory. This
will make separating sys_util and crosvm independent making it easier
to use sys_util functions outside of crosvm.
Change-Id: I12e14948ea85754dfa6267b3a3fb32b77ef6796e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2311251
Auto-Submit: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This change includes support for core scheduling in sys_util and the
usage of it within the vcpu threads.
Because the core scheduling prctl is not yet stabilized, this feature is
specific to Chrome OS for now. To indicate this, the new "chromeos"
feature has been added to the appropriate Cargo.toml files.
TEST=cargo build --features "chromeos plugin"
BUG=b:153989878
Change-Id: I8b6ce00b26c482739536b632f08e55264dc513a0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2284184
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Auto-Submit: Zach Reizner <zachr@chromium.org>
This will allow it to be disabled for Protected KVM usecases on Android.
BUG=b:158290206
TEST=cargo test
Change-Id: Ibddd8a98c42bb0847aba804f5e33df29feedd783
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2292372
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Convert the FD executor to have a more similar interface to the
uring_executor. This has two benefits.
1) This allows a single wrapper `PollOrRing` to be used. It will select
uring or fd transparent to the user, allowing users to get the benefits
of uring when available without changing their code.
2) Having the `PendingWaker` and Registered source manage FD lifetime
removes the need for custom drop implementations for each Future. This
simplifies things so much there is no longer need for the async_core
crate which is removed.
Change-Id: Ic6c84c4e668cbfe5eddeb75129b34d77f66b096d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2227087
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
io_jail has been migrated to aosp/external/minijail/rust/minijail.
This removes the crosvm copy and updates the references to use the new
location.
BUG=chromium:1096175
TEST=cargo test
Cq-Depend: chromium:2254418
Change-Id: I29d5c6178b6faf5e52671cfbe6fc7e51f0d21dd2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2254298
Tested-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Allen Webb <allenwebb@google.com>
This matches the version of libc in the Chrome OS tree (dev-rust/libc).
Fixes non-Portage builds due to a change in the type of S_ISGID:
457b0f9902
Previously this would fail compilation with an error about "no
implementation for `u32 & i32`".
Updated with:
cargo update -p libc --precise 0.2.65
BUG=None
TEST=bin/clippy
Change-Id: Ibe3043162a5af7c69168ec61fee3f4cdc35044e8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2258621
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This CL adds a fundamental part of the virtio video device, which will
be shared between the encoder and the decoder.
Both devices uses the virtio-video protocol proposed as RFC v3 [1,2].
The corresponding driver code is at CL:2060327 and its children CLs.
The actual decoding and encoding logic will be implemented in different
CLs.
[1]: mail: https://markmail.org/thread/wxdne5re7aaugbjg
[2]: PDF: https://drive.google.com/file/d/1jOsS2WdVhL4PpcWLO8Zukq5J0fXDiWn-/view
BUG=b:147465619, b:140082257
TEST=cargo check --features=video-decoder,video-encoder
TEST=ARCVM started with --video-decoder --video-encoder
Cq-Depend: chromium:2203997
Change-Id: I01999eea218ba0f3aaed1558ca2311a57d0c6819
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1973973
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This is a separate hypervisor crate for interacting with Kvm in an
abstract manner. The intention is to not leak the internals of kvm
with its specific calls in various places in the codebase. Currently,
this just creates an initial structure for adding various
implementations over time.
In addition, a SafeDescriptor class is added, that wraps a raw file
descriptor safely, without needing to wrap it in the rust file class.
The intention is to use this for non file raw descriptors.
BUG=chromium:1077058
TEST=added a basic kvm test that creates a Kvm struct
Change-Id: I4229203902e480b52435cde12bf0d25a322c71be
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2174756
Commit-Queue: Udam Saini <udam@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The basic ACPI table support for creating XSDT.
It refers to the implementation of the Cloud-hypervisor's ACPI
commit:
- Cloud-hypervisor: acpi_tables: Add initial ACPI tables support
BUG=chromium:1018674
TEST=cargo test -p acpi_tables
Change-Id: Ia3b597936fef214fcb92fce28c91152dfa03bec9
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035350
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Adds a new backend type, gfxstream, that calls out to a C library
implementing the actual rendering.
The purpose is to allow the Cuttlefish and Android Studio Emulator teams
to use crosvm with the current API-forwarding style of rendering
employed in the Android Studio Emulator.
Also, introduces a new key to the --gpu command line interface,
backend=, which selects from different backends. Note that the previous
behavior is now deprecated and will be removed after some time
(when all clients switch over to backend=).
The gfxstream backend itself implements a subset of 3d-related resource
and context creation/transfer/execbuffer commands. Their meaning is
specific to the way in which they are interpreted in the backend
library.
To interface with display, gfx stream backend takes a callback that is
run on guest vsync. The callback is responsible for repainting the
display's contents. gfx stream provides a callback, get_pixels, that can
be used asynchronously. The asyncness is not taken advantage of
currently but will be useful for cases where the client attached to the
VMM might want to update at a different rate than guest vsync.
The guts of the stream backend library is currently defined here:
https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-master-dev/android-qemu2-glue/emulation/virtio-goldfish-pipe.cpp
The linking of the library is controlled via the feature "gfxstream".
If the feature is turned off, we use a default do-nothing stub impl.
Next steps:
- integrate virtio-gpu-next so as to have host coherent memory for
vulkan
- Figure out low latency command submit/response with SUBMIT_CMD_3DV2
BUG=b:146066070
Change-Id: If647381c15e5459cec85e2325f97e2f0a963b083
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2033305
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Auto-Submit: Lingfeng Yang <lfy@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
This crate will provide asynchronous helpers wrapping primitives
provided by sys_util. To start EventFDs and MsgReceivers are provided.
Change-Id: Ia8862adafca995a3e3ab56582acc166a37fc8d2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1955046
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
This crate will house code using the new async/await features to be used
by other parts of crosvm.
Start the crate with a Future executor that runs tasks in a single
thread and allows futures that block on system file descriptors.
Change-Id: If77778ac056210dabbfc6e6e1e63df1c1b904a7f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1955045
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Move qcow from being its own crate into a module of the disk crate,
similar to the composite disk module.
This will allow use of qcow from disk and vice versa without introducing
a circular crate dependency.
BUG=None
TEST=./build_test.py
TEST=USE='asan fuzzer' emerge-nami crosvm
Change-Id: I77512bbe4b94faff1b5460f9796ee56505135580
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1972477
Reviewed-by: Cody Schuffelen <schuffelen@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Drop the dependency on libusb and reimplement the host USB backend using
usb_sys to wrap the Linux usbdevfs ioctls.
This allows sandboxing to work without any dependency on libusb patches,
and it gives us the flexibility to modify and update the USB backend
without depending on an external third-party library.
BUG=chromium:987833
TEST=`adb logcat` on nami with Nexus 5 attached
TEST=deploy app to phone with Android Studio
TEST=Run EdgeTPU USB accelerator demo (including DFU mode transition)
Cq-Depend: chromium:1773695
Change-Id: I4321c2b6142caac15f48f197795a37d59d268831
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1783601
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This adds a new disk file type next to raw files and qcow images that
represent an indirection to further raw disk files. The disk file
itself is a proto file with references to file paths for other disks to
open and their virtual offsets and lengths.
The intention is to make it easy to assemble a single virtual hard disk
out of several distinct partition files. In the particular case of
Cuttlefish running Android in a VM, this is relevant as the Android
build system distributes partitions as separate raw files. While the
simple solution is to pass each partition as a separate raw disk, some
functionality (like the bootloader) assumes there is a partition table
with multiple distinct partitions on a single disk.
Implementing composite disk support in the VMM bridges this gap through
supporting the general-purpose case of a disk built out of multiple
component files.
If desired, this can be extended to support qcow files to support
unusual configurations like a mixed qcow/raw disk.
Enabled with the "composite-disk" feature.
Bug: b/133432409
Change-Id: I2b0c47d92fab13b5dc0ca5a960c7cfd2b7145b87
Signed-off-by: Cody Schuffelen <schuffelen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1667767
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
With this, crosvm builds that don't have the CrOS version of
virglrenderer can build against master without adjustments.
BUG=chromium:924405
TEST=compile
Change-Id: Iee27c003bee1eb8947cb048dc16e2da6c68af11e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1797067
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Remove the last (unused) reference to byteorder in vm_control/Cargo.toml
and remove it from the list of external crates in README.md.
BUG=None
TEST=./build_test
Change-Id: Ie70c0bc2f96c19b34ef1596885245eca7bc202f4
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1761156
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This change has 3 parts:
- Modify the Cargo.toml to point at the bin and the lib source.
- Move modules and Config struct into the lib source
- Fix the argument/plugins module's doc comments which had never been
tested.
The motivation for this change is to make testing crosvm's major
functionality (booting guest kernels, emulating hardware, etc) easier to
do from a cargo test. Being able to launce a crosvm config via the API
instead of the binary's command line will be possible with this change.
A side benefit is that this also enables doc tests in the lib side of
crosvm. The doc tests in binaries are not run due to a limitation in how
they get tested by cargo.
TEST=cargo test
./build_test
kokoro/kokoro_simulator.sh
emerge crosvm
BUG=None
Change-Id: I9d4b3a24231b895e8dfaf9e7b0f2b33350772041
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1730333
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
This change adds an X11 backend to the gpu_display crate. With this
addition, the virtio-gpu device can display to traditional linux
desktops that only have X11 output.
Change-Id: I86c80cac91ca5bdc97588194a44040273ae69385
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1591572
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Zach Reizner <zachr@chromium.org>
This CL fixes four cases of what I believe are undefined behavior:
- In vhost where the original code allocates a Vec<u8> with 1-byte
alignment and casts the Vec's data pointer to a &mut vhost_memory
which is required to be 8-byte aligned. Underaligned references of
type &T or &mut T are always undefined behavior in Rust.
- Same pattern in x86_64.
- Same pattern in plugin::vcpu.
- Code in crosvm_plugin that dereferences a potentially underaligned
pointer. This is always undefined behavior in Rust.
TEST=bin/clippy
TEST=cargo test sys_util
Change-Id: I926f17b1fe022a798f69d738f9990d548f40c59b
Reviewed-on: https://chromium-review.googlesource.com/1566736
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
To avoid wasting time re-sorting these things (CL:1492612).
https://docs.rs/remain
Disclaimer: I wrote the macro.
This CL adds #[sorted] attributes to those Error enums that seemed to
have made some effort to be in sorted order.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
TEST=emerge-nami crosvm
TEST=local kokoro
CQ-DEPEND=CL:1524247
Change-Id: I89685ced05e2f149fa189ca509bc14c70aebb531
Reviewed-on: https://chromium-review.googlesource.com/1515998
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This de-duplicates the two separate build.rs files dealing with proto
compilation. The trunks interface.proto will be exposed under
protos::trunks and the plugin proto will be exposed under protos::plugin.
BUG=none
TEST=cargo check
TEST=cargo check --features tpm
TEST=cargo check --features plugin
TEST=cargo check --features tpm,plugin
TEST=FEATURES=test emerge-nami crosvm
TEST=FEATURES=test USE=crosvm-tpm emerge-nami crosvm
TEST=FEATURES=test USE=crosvm-plugin emerge-nami crosvm
TEST=FEATURES=test USE='crosvm-tpm crosvm-plugin' emerge-nami crosvm
TEST=local kokoro
CQ-DEPEND=CL:1553971
Change-Id: I203b654a38e9d671a508156ae06dfb6f70047c4f
Reviewed-on: https://chromium-review.googlesource.com/1556417
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This matches the version already used by crostini_client.
The newer protobuf version depends on the tempfile crate rather than
tempdir, the latter being now deprecated. So I replaced our immitation
tempdir crate with one that matches the API of tempfile instead. As a
reminder, we use this crate as a patch to avoid pulling in all of the
rand crate and its many dependencies.
TEST=cargo check --features plugin
CQ-DEPEND=CL:1553971
Change-Id: I28eed3ceadb1013f015400b4c582aaf8dc89eee1
Reviewed-on: https://chromium-review.googlesource.com/1562924
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This may help reduce cases of conflicts between independent CLs each
appending a dependency at the bottom of the list, of which I hit two
today rebasing some of my open CLs.
TEST=cargo check --all-features
Change-Id: Ief10bb004cc7b44b107dc3841ce36c6b23632aed
Reviewed-on: https://chromium-review.googlesource.com/1557172
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>
Separated out of CL:1513058 to make it possible to land parts
individually while the affected crate has no other significant CLs
pending. This avoids repeatedly introducing non-textual conflicts with
new code that adds `use` statements.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: If27a414db82bd6005d8067af24639f309d3b5e2e
Reviewed-on: https://chromium-review.googlesource.com/1519691
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This cleans up some feature flag plumping for libusb sandboxing as well.
BUG=chromium:831850
TEST=cargo test
CQ-DEPEND=CL:1512762
Change-Id: Ic70784db204ddced94498944b021bcb7dd708bb1
Reviewed-on: https://chromium-review.googlesource.com/1522214
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Jingkui Wang <jkwang@google.com>
Builders of crosvm, such as the crosvm ebuild, should determine if they
want LTO enabled. By having lto removed from the release profile,
builders using `--release` will not be forced to use LTO.
BUG=None
TEST=cargo build --release should be heckin' fast
Change-Id: I4e231b6dac7670ab146d36c1c1660ab67935285a
Reviewed-on: https://chromium-review.googlesource.com/1497734
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: Chirantan Ekbote <chirantan@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>
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>
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>
the few uses of rand::thread_rng() have been replaced with either
prngs or reads from /dev/urandom. the implementations are under
the `rand_ish` minicrate.
`protoc-rust` depends on `tempdir`, which relies on rand, so
`tempdir` has been patched with a rewritten version that does not
have rand as a dependency.
BUG=chromium:921795
TEST=cargo test --features plugin
Change-Id: I6f1c7d7a1aeef4dd55ac71e58294d16c291b8871
Reviewed-on: https://chromium-review.googlesource.com/1409705
Commit-Ready: Daniel Prilik <prilik@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
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>
make open_fd patch optional. if sandboxed-libusb feature is not selected,
open_fd is not required.
In this case, the code must have access to /dev/bus/usb, and not
external fd is needed.
BUG=chromium:831850
TEST=cargo test
Change-Id: I21fa87dd15d08a03c2fe2b190559abbe6f63dcd5
Reviewed-on: https://chromium-review.googlesource.com/1375019
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
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>
This wrapper will be part of usb emulation backend.
BUG=chromium:831850
TEST=local build
Change-Id: I084b15201941e4c16c4e3ff9b967e55db09db567
Reviewed-on: https://chromium-review.googlesource.com/1124870
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Jingkui Wang <jkwang@google.com>
The qcow_utils crate is not a dependency of crosvm and should not be
built in the same phase as crosvm. Doing so was harmless before the
recent rustc/cargo changes, which seem to be triggering some kind of
race condition. This change works around the bug.
CQ-DEPEND=CL:1336738
TEST=cargo test --release
BUG=chromium:900366
Change-Id: I01048128b20cf06580e809f6701688ab72e7756d
Reviewed-on: https://chromium-review.googlesource.com/1336737
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This will harden crosvm against potential integer overflow leading to
unsafe behavior in unsafe blocks.
TEST=cargo test --release
BUG=None
Change-Id: Ie750906d04c6ef8cb9400b976827c2abeab2ab56
Reviewed-on: https://chromium-review.googlesource.com/1282064
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
MsgSock wraps UnixDatagram and provides simple macro to define Messages
that could be send through sock easily.
TEST=cargo test
BUG=None
Change-Id: I296fabc41893ad6a3ec42ef82dd29c3b752be8b8
Reviewed-on: https://chromium-review.googlesource.com/1255548
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add the 9s crate, which provides an executable that can serve the 9p
file system protocol. It initially only supports connections over vsock
but can easily be extended to support network and unix domain socket
based connections.
BUG=chromium:703939
TEST=Run the server, have maitred connect to it over vsock, mount the
9p file system in the guest kernel, share it with the penguin
container, and run `bonnie++ -r 256 -s 512`
CQ-DEPEND=CL:1121550, CL:1166446
Change-Id: Ia0c72bcf29188bba4c07b6c0a2dd5a83d02339b5
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1112870
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Support macro derive(BitField) to make life easier.
BUG=None.
TEST=local build and run test.
Change-Id: I582620de250017fb7c0b601f9ad4fbcbbc2fe02a
Reviewed-on: https://chromium-review.googlesource.com/1069331
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@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>
Basic 2D and 3D support is there. The drm_cursor_test and
null_platform_test in drm-tests should run to completion.
The extra device is hidden behind both a build time feature called 'gpu'
and the device is only added to a VM if the '--gpu' flag is given.
TEST=build with --features=gpu;
drm_cursor_test && null_platform_test
BUG=chromium:837073
Change-Id: Ic91acaaebbee395599d7e1ba41c24c9ed2d84169
Reviewed-on: https://chromium-review.googlesource.com/1036862
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
These bindings are needed for virtio-gpu 3D capabilities.
All the rust files under gpu_renderer/src/generated are generated via
the gpu_renderer/src/generated/generate script.
The gpu_renderer/src/lib.rs file contains the Renderer and Context
structs, which are the main interfaces to virglrenderer. They
encapsulate the global state of virglrenderer (Renderer) and each
context ID (Context).
The command_buffer module is included only for basic testing and is not
intended for production use.
The pipe_format_fourcc module is provided for the conversion of
virglrenderer specifc formats to standard fourcc formats.
BUG=chromium:837073
TEST=cargo build -p gpu_renderer
CQ-DEPEND=CL:1144406
Change-Id: Iad153390f618309bf493e92e76432c0b1c4a8a93
Reviewed-on: https://chromium-review.googlesource.com/1043447
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Combine GPU buffer allocation with the system resource allocator making
life easier as only one allocator needs to get passed to the execute
function.
Change-Id: I199eb0fd6b99b629aaec1ae3295e8a1942da5309
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1099856
This provides virtual display style output, useful for debugging
virtio-gpu. Although using virtio-gpu for display purposes clashes with
the more integreated virtio-wayland support, it is nonetheless helpful
for debugging virtio-gpu, and is technically required to fully implement
that device.
TEST=cargo build -p gpu_display
BUG=chromium:837073
CQ-DEPEND=CL:1096300
Change-Id: I59f895e951ef593d4119e7558168dd34223519ee
Reviewed-on: https://chromium-review.googlesource.com/1043446
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Allow IRQs to be assigned before creating device manager.
For PCI, we need to add devices with interrupts before MMIO setup. Add
the ability to tell the architecture device manager about IRQs that we
have stolen.
There was only one function in device_manager and all of its state is
now delegated to the resource allocator, remove it.
Change-Id: I9afa0e3081a20cb024551ef18ae34fe76a1ef39d
Reviewed-on: https://chromium-review.googlesource.com/1089720
Commit-Ready: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Add the AddressAllocator module that will be used by both architectures
to manage distributing address ranges to devices. This will make the
addition of PCI devices easier as now both MMIO and PCI will need to
share address space. Add this to a new resources crate.
Change-Id: I6a971dd795f2118bd6cfec7dc34a65b0d4a32f9b
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1072570
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
The p9 crate needs the libc::DT_UNKNOWN constant, which isn't available
in version 0.2.34 but is available in version 0.2.40.
BUG=chromium:703939
TEST=none
CQ-DEPEND=CL:1065064
Change-Id: If1451d5bcc2737abc2a14d2b81005c6318165e1f
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1013202
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Implement encoding and decoding various primitives using the p9
protocol. In addition, add a procedural macro to derive the encoding
and decoding implementation for structs built out of the primitives.
BUG=chromium:703939
TEST=unit tests
CQ-DEPEND=CL:1065063
Change-Id: I7256633fb7002da9ce8af03be2f24410b90ccf3f
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/969965
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This implements DMABuf allocation type in the virtio wayland
device.
We attempt to locate a supported DRM device prior to engaging
the device jail. If found, the DRM device is passed to the
wayland device code and used to serve DMABuf allocations.
DMABuf support can be disabled by not providing crosvm with
access to any DRM device nodes.
The guest is expected to handle the case when DMABuf allocation
fails and fall-back to standard shared memory.
This initial change uses DRM directly but is structured in a
way that would allow the allocator to be replaced by minigbm
with minimal effort.
BUG=chromium:837209
TEST=crosvm finds drm device and returns valid dmabufs to guest
Change-Id: Ic1fd776dfdfefae2d7b321d449273ef269e9cc62
Reviewed-on: https://chromium-review.googlesource.com/1034088
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: David Reveman <reveman@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add a build-time feature that allows having plugin and other parts of
crosvm to run outside of jailed environment. This is strictly a
development time feature and is not expected to be activated with
shipping code.
Sandbox can still be activated by passing -u (--multiprocess) option.
BUG=None
TEST=cargo test --feature=default-no-sandbox
Change-Id: If9ef1ce8ed0b5d23cef3ad193679baca94413360
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1054194
Reviewed-by: Zach Reizner <zachr@chromium.org>
These bindings are needed to allocate dmabufs that will be used for
accelerated rendering and zero-copy virtio-wayland support.
TEST=cargo test -p gpu_buffer
BUG=chromium:837073
Change-Id: I96d7bcdeaa1eda616a25fdcfedcbb734cd585ae7
Reviewed-on: https://chromium-review.googlesource.com/1029410
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
- removes old ARMv7a (32-bit) bindings as we're only supporting aarch64
guests right now
- switches both ARMv7 and aarch64 builds to use aarch64 kvm bindings
- adds support for ARMv8 Linux guest with dynamic flattened-device-tree
CQ-DEPEND=990894
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
TEST=crosvm runs on kevin built with USE="kvm_host"
Change-Id: I7fc4fc4017ed87fd23a1bc50e3ebb05377040006
Reviewed-on: https://chromium-review.googlesource.com/969987
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This creates a trait that different architectures can implement to
support running Linux VMs.
In the implementation on X86 we remove some error and return errors
from lower-level modules as appropriate. These modules now implement
the Error trait so we can get meaningful descriptions without an extra
error from the calling function. This still keeps all the ifdefs in
linux.rs for now until we have another implementation to use for ARM.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: If24bcc83e25f9127d6aea68f9272e639296aad8b
Reviewed-on: https://chromium-review.googlesource.com/952368
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
I will be refactoring this code to mostly live in the architecture
code, but for now it's simpler to move it out into it's own crate.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: I85c12696fcd5cbef6a72a6dcbc484a443e0b0784
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/933084
The debug registers are useful to access for the plugin process in some
cases.
TEST=cargo test --features plugin; cargo test -p kvm; ./build_test
BUG=chromium:800626
Change-Id: I8f3f6c31c6989061a43cef948cf5b4e64bd52d30
Reviewed-on: https://chromium-review.googlesource.com/896945
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The plugin process is good for running a VM that depends substantially
on devices that aren't implemented inside of crosvm.
TEST=cargo build --features plugin; ./build_test
BUG=chromium:800626
Change-Id: I7b4f656563742cd0bedc837205dd1240d497941d
Reviewed-on: https://chromium-review.googlesource.com/869357
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This is the shared library used by the plugin process to speak to a
crosvm main process that spawned it.
TEST=cargo build --features plugin
BUG=chromium:800626
Change-Id: I100e7ddfc1099fbdf1462c171785a861e075d5d7
Reviewed-on: https://chromium-review.googlesource.com/869356
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
We'll want architecture code to be able to supply and manipulate Linux
kernel command lines, so let's move this out to it's own crate and
export the interfaces.
BUG=chromium:797868
TEST=./build_test passes on all architectures
TEST=crosvm runs on caroline
Change-Id: I94904055ac02582a4f4d8bbb54d0f41ed14b955d
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/898351
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This slightly advances the use of fakes to test higher level
application logic. The fakes are rudimentary at this point, but I
wanted to get feedback on the addition of generics in order to
facilitate swaping concrete implementations out with fakes in higher
level code.
BUG=none
TEST=./build_test and
cargo test -p crosvm -p data_model -p syscall_defines -p kernel_loader
-p net_util -p x86_64 -p virtio_sys -p kvm_sys -p vhost -p io_jail -p
net_sys -p sys_util -p kvm
Change-Id: Ib64581014391f49cff30ada10677bbbcd0088f20
Reviewed-on: https://chromium-review.googlesource.com/689740
Commit-Ready: Jason Clinton <jclinton@chromium.org>
Tested-by: Jason Clinton <jclinton@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This C library will be use by the VM launcher to create the qcow2 files
used for persistent VM data.
CQ-DEPEND=CL:884263
BUG=none
TEST=cargo test --all -- --test-threads=1
Change-Id: Ibd7f71d2e3f1f72f781978f014865d2161f033f5
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/875116
QCOW2 files will be used to store the VM's data on ChromeOS. Add
support for basic reading and writing of qcow files.
CQ-DEPEND=CL:872451
BUG=none
TEST=qcow unit tests and use "qemu-image check" to verify generated qcow
files.
Change-Id: I4b9e77e58edca69f894ede19e79ebd2cd7b2623e
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/862628
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Getting and settings seals is useful to ensure the size of files
underlying memory mappings doesn't shrink, which can trigger a SIGBUS on
access to the truncated pages.
This also bumps the libc version to get MFD_ALLOW_SEALING.
TEST=cargo test
BUG=None
CQ-DEPEND=CL:850535
Change-Id: Ifbe1ec2c47d3d5c51b63472f545acc10d3c8eed2
Reviewed-on: https://chromium-review.googlesource.com/849488
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Making the project a workspace allows running all local libs unit tests
from the main build.
Change-Id: Ib531dd10c21f324c7d25af69ad12b95c7bc8f3bc
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/759597
Reviewed-by: Zach Reizner <zachr@chromium.org>
Moving the devices to their own module makes it easier to add tests that
use them.
Change-Id: I61bfef4037d16b20145b5fddce604835cdc4f67b
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/706559
Reviewed-by: Zach Reizner <zachr@chromium.org>
Break out vm_control to a crate that will be able to used by more
modules. Having vm_control usable from outside crosvm makes it possible
to move the devices out of crosvm in a later commit.
Change-Id: I1f060700ed49b5d77519d55efa2430490d521256
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/706558
Reviewed-by: Zach Reizner <zachr@chromium.org>
