We can use MaybeUninit instead of heap allocation to ensure that our
buffer has the proper size and alignment. `from_reader` is used for
every message in the fs device and this saves us some unnecessary small
heap allocations.
Switch Reader::read_obj to use this method so that we don't have
multiple implementations of the same thing. This also fixes some
unsoundness in read_obj where we were creating a `&mut [u8]` out of
uninitialized data.
BUG=none
TEST=unit tests
Change-Id: I1fa66de11974e2fe3a8dfb4b7ab4b210ecf395d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3109088
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
This way we're not required to transfer ownership every time we call
`handle_message`.
BUG=none
TEST=unit tests
Change-Id: Ia0cc10c7b5431e8bb90afbc0b658efac33eef6c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3105916
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Starting with glibc 2.33 the faccessat2 syscall is used and
only if it doesn't exist (eg kernel older than 5.8) glibc will
default to the older faccessat syscall, so we need to allow it.
Previously this syscall has been enabled on a per-component
basis after testing, but this one does a bulk enable when
faccessat is used on all architectures.
See glibc commit 3d3ab573a5 ("Linux: Use faccessat2 to implement
faccessat (bug 18683")
BUG=b:187795855
TEST=Local builds; CQ.
Change-Id: I1f17e82e8c416b0fa2c43342731e9ea8394c47fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3097212
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Make run_*_device() return an error instead of printing error messages
so that the caller of the functions can handle errors from each device
in the same manner.
BUG=b:195495971
TEST=cargo build
Change-Id: I1b464b8bedbe6d4e640084a2ad3b2565d11b9e07
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3099429
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
We originally created `vhost_user_devices` crate so that we'll be able
to have device executables there.
However, we decided to have vhost-user device as crosvm's subcommand.
So, we have no longer a reason to have vhost-user devices as the
separate crate. As the first step to remove the vhost_user_devices
crate, this CL move its main logic to the devices crate.
Note that we add `vhost_user_devices/src/*_device.rs` in this CL as we
need to keep the device executables for a while.
BUG=b:195495971
TEST=cargo build
Change-Id: I355b9cd35214ac0c3d8ffd6fbebc29dd7548fd61
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3070723
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This is a commit to future-proof seccomp failures with syscall=100,
fstatfs. On 32bit systems, we've seen programs which use not just
fstatfs64, but also fstatfs. Which one is selected is seemlessly
selected via defines via `statvfs`, depending on the board
(notably scarlet, trogdor, and elm).
See also: https://man7.org/linux/man-pages/man2/statfs.2.html
BUG=b:197006863
TEST=CQ
Change-Id: I6eaea3064671a109d2d7844cde4eae43931c63bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3100412
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Rename `devices::virtio::vhost::user` to
`devices::virtio::vhost::user::vmm` so that we'll be able to put
device-side code in the same module later.
BUG=b:195495971
TEST=cargo test
Change-Id: Ice039125bcba61555c7a58fa0ca46aaa643ee605
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3096440
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Move the definitions of SerialHardware, SerialParameters and SerialType
to the devices crate so that they'll be available for code in the
devices crate as well.
BUG=b:195495971
TEST=cargo test
Change-Id: Ieb711bdb18a8afdb28cac262a3355739604d4607
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3096439
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
One vm may have one vfio kvm file only, it could be created at vm
setup or runtime through vfio-pci hotplug, make it as global to
satisfy these two cases.
When vfio pci device is removed throgh hotplug out, the vfio group
will be removed frome vfio kvm file also, so move it into vfio.rs,
so it is could be referenced at vfio group's destroy. And
vfio group's destroy is called from vcpu thread, while vfio kvm file
is created in main thread, so use OnceCall instead of thread_local.
BUG=b:185084350
TEST=Boot a vm with or without passthrough device
Change-Id: I780c43a0ac0265f1e6f62578e134d09cbefc3e2f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3062741
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Hotplugged device will be configured at runtime and configure_pci_device()
will allocate resource for added device and put this device into LinuxVm.
BUG=b:185084350
TEST=Boot a guest with and without passthrough device
Change-Id: I2c77f006d135c1b1487d4e89a50b1b186beeb48e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954671
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The previous implementations were exactly the same as the macro
expansions, so this should be exactly the same but less verbose.
BUG=None
TEST=cargo test
Change-Id: I9c97c4c9cb71491d5f8f5a8ce52e64abdac54245
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026666
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Andrew Walbran <qwandor@google.com>
Commit-Queue: Andrew Walbran <qwandor@google.com>
This lets us offload the blocking accept() call to another thread so
that the main thread can continue handling other operations.
BUG=b:179755651
TEST=cargo test
Change-Id: I1372a13e662fe4ad5c99764788550a444d46170d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2987588
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
A lot of the information was outdated. The new guide prioritizes
building for linux and testing on linux as the default workflow
for crosvm.
BUG=b:194323235
TEST=None
Change-Id: Idb7cdb07151fc7d7d5466075e316015cf5f4c615
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3098391
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This allows ChromeOS developers to use cargo to build against the crates
provided by the ChromeOS source tree, instead of using the bundled
submodules.
BUG=b:196585250
TEST=./setup_cros_cargo.sh && cargo build
Change-Id: I02d38784f7a97657c37c267818499efed4ddab47
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3092414
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
A MSIX BAR can include both MSIX and non-MSIX registers. The non-MSIX
part of the BAR can be mmaped, eliminating unnecessary slow reads/writes
in userspace.
Add a new struct, VfioMsixAllocator, to keep track of the non-MSIX areas
of a mappable MSIX BAR. Page alignment is imposed to make sure mmap
succeeds.
BUG=b:184904868
TEST=boot Linux kernel and verify MSIX-capable passthru devices work
properly
Change-Id: I1fbf4c710f4bfaffe613d902f27e3bbb558c469e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2972489
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
num_pba_entries should use rounding instead.
BUG=b:184904868
TEST=boot Linux kernel and verify MSIX-capable passthru devices work
properly
Change-Id: I406c033f59bc50bd767116947525058b74be054f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2972488
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
For MSIX-capable PCI devices, some BAR regions are described using
VFIO_REGION_INFO_CAP_MSIX_MAPPABLE:
The MSIX mappable capability informs that MSIX data of a BAR can be
mmapped which allows direct access to non-MSIX registers which
happened to be within the same system page.
Add support for this capability so that VfioRegion stores the correct
mmaps information.
Also, fix a couple break conditions to avoid breaking out early.
BUG=b:184904868
TEST=boot Linux kernel and verify MSIX-capable passthru devices work
properly
Change-Id: Ie451b154ccd4779f1694a1ffed0bd02127f5ecdb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2972487
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
BUG=b:191784608
TEST=Build and run atest in Android tree
Cq-Depend: chromium:3073700
Change-Id: I5fcfa166caf8c5a5f759a8f62ef78a293db95f1a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3071900
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andrew Walbran <qwandor@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Protected VMs require all virtio data to be bounced through a memory
window shared between the host and the guest. Although this can be
achieved by forcing the guest to use swiotlb bouncing for all DMA
transfers, the recent introduction of "Restricted DMA" in Linux allows
these buffers to be sized and allocated on a per-device basis.
Remove the 'swiotlb=force' option when '--protected-vm' is set in favour
of describing a reserved memory region to be used as the swiotlb buffer
for all virtio-pci devices, adjustable via the new '--swiotlb' option.
BUG=b:190593703
TEST=cargo test on x86 and arm64 machines
Cc: David Brazdil <dbrazdil@google.com>
Cc: Claire Chang <tientzu@chromium.org>
Cc: Quentin Perret <qperret@google.com>
Cc: Andrew Walbran <qwandor@google.com>
Cc: Marc Zyngier <mzyngier@google.com>
Change-Id: I2d48a7c77740e7f3ad996ad33592f0acd53b7144
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3064198
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Will Deacon <willdeacon@google.com>
Reviewed-by: Andrew Walbran <qwandor@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Having both renderers running at the same time can work,
but not without changes. For now, allowing building both
at the same time.
BUG=b:181869105, b:182174209
Test: launch_cvd --gpu_mode=gfxstream
Test: launch_cvd --gpu_mode=virgl_renderer
Change-Id: Ib8a3fd4927401b9f7ebc4a4425a3ddba6621a3e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3092405
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
When nothing fails, output is ignored, but when something fails, you'd
want to look at the error messages.
BUG=None
TEST=time ./builder --vm ./run_tests
Change-Id: If6e73588b33714dea1e7f097a91c80f7c249be48
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3083207
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
The conversion code for KVM <-> hypervisor representation of the Local
APIC state used the unsafe mem::transmute() function to view an array of
i8 as u8 instead for use with the Rust endian conversion functions.
Casting between integer types of the same size with `as` is defined in
Rust as a "no-op" (the bitwise representation is preserved), just like
in C, so transmuting at the slice level is not needed. These can instead
be written as simple loops to avoid the unsafe code.
To ensure this does not regress code quality, I have compared the code
generated for the x86-64 release build. The kvm_lapic_state to
LapicState conversion compiles to identical code, and the reverse
compiles to slightly different code (the compiler decides to emit a loop
instead of unrolling the 64-element copy), but the conversion of each
element still compiles down to a pair of MOV instructions.
The corresponding unit test has also been updated to avoid transmute, as
it was unnecessary there - the individual array element can be cast with
the `as` operator rather than transmuting the whole array.
BUG=None
TEST=cargo test -p hypervisor
Change-Id: I7e792b5507235e5234afe114a1ca744931e047d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2947934
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Improve the log message for unexpected commands received on control
endpoints to include the type of command.
BUG=chromium:1231779
TEST=./test_all
Change-Id: I29963739bf5c5cb9fa427011fe5468a7378b67e3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3083225
Reviewed-by: Abhishek Bhardwaj <abhishekbh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Cathedral enthusiant Victor Hugo once said:
“Nothing else in the world ... not all the armies ... is so
powerful as an idea whose time has come.”
He was talking about republicanism vs. monarchy. My friends,
we are on the verge on a change quite possibly bigger than
that: seamless wayland windowing!!
The revolution started by the virtio_wl device is finally making
it's way to virtio_gpu, bringing best-in-class display
virtualization to a wider audience.
The overall approach is described here:
goto.google.com/virtio-gpu-wayland-context
At it's core, virtio-gpu wayland windowing uses the same mechanisms
that another virtio-gpu consumer (say gfxstream or virglrenderer)
uses to submit an opaque command stream to the host. A response
page is allocated by the guest where host commands are place
(gfxstream has been using this mechanism for years).
There are various tables to track the internal context state and
resources. A thread is spun up to poll the Wayland socket. The
asynchronous callback and upcoming virtio-gpu multiple timelines
feature is used to make 3D consumers (gfxstream, virglrenderer)
don't interfere with the Wayland signalling.
In the future, virtio-gpu may be further modifed to perform
multi-queue virtio in-case the single virtio-queue turns out to be
a bottleneck.
As always, look forward to your feedback & questions.
BUG=b:150239451
TEST=Launch Sublime text + weston-terminal with Sommelier changes
Copy + paste into VM window
Copy + paste out of VM window
Change-Id: Ifb74644cc71a561fd278700d91e4bc66d16107a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3055850
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Add an optional deadline to BlockingPool::shutdown. Any worker threads
that have not yet exited once the deadline expires will be detached.
This ensures that we don't end up blocking indefinitely while waiting
for worker threads to exit.
BUG=none
TEST=unit tests
Change-Id: I6d7e73e1c95a934a4fd80825a9d44187532408b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3058842
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
According to pci bridge spec, some registers are writable and should
be marked correctly.
BUG=b:185084350
TEST=Boot a guest with pcie root port
Change-Id: I501fa05cc9ea6b6ea02d5d8bcbb29ba291a4b49e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954675
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Some pci capability register is writable, and guest could write it
and control it(like msix control and pcie cap control), let each
pci capability returns its writable bits, so guest could write the
value into config register.
BUG=b:185084350
TEST=Boot a guest with and without passthrough device
Change-Id: Ic98a569823c762e7165f83d29ee90d2ba762dead
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954674
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This is used to finally make a "delay-rt" VM's RT VCPUs RT.
BUG=b:142777321
TEST="grep policy /proc/<pid of rt vcpu>/sched" to make sure RT vcpu
isn't RT until "make_rt".
Change-Id: I73177f8adadf3d1099c2b09871ee9d5feab82587
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2703225
Auto-Submit: Suleiman Souhlal <suleiman@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Suleiman Souhlal <suleiman@chromium.org>
This flag is intended to be used to delay making a VM's RT VCPUs
RT until "make_rt" is called, in order to avoid boot time
regressions with RT.
BUG=b:142777321
TEST="grep policy /proc/<pid of rt vcpu>/sched" to make sure RT vcpu
isn't RT until "make_rt".
Change-Id: I1b9132e11f0acc626434c60cecc2f4afe350961a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2703224
Auto-Submit: Suleiman Souhlal <suleiman@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Suleiman Souhlal <suleiman@chromium.org>
The ForceKeyFrame control is a button control, which means that it
doesn't have a value. This CL performs some minor cleanup and removes
the empty parentheses after the ForceKeyFrame CtrlVal as these are not
required.
BUG=None
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Ic86eb92e097de46ce68ed71bfe24299e07f8b78e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3064155
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
/tmp is mounted as tmpfs, and tmpfs does not provide O_DIRECT capabilities. Try
using a ext4 file system.
BUG=b:190435784
TEST=time ./ci/builder --vm # boot_test_vm_odirect passes
Change-Id: I3f8245052ed06c703cc3aa320d300d5f21254e90
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3083206
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Stale balloon stats results can be returned from a stats request for the
following reasons:
* The initial stats buffer from the guest is posted to the
balloon_host_tube without a request.
* Balloon stats requests can fail because the balloon device isn't
completely set up yet; writing a stats request to the tube without
reading the response.
* Balloon stats requests can time out, returning an error. When the
balloon stats are eventually computed, they will be queued to the tube
without a read to consume them.
Possibly other reasons too.
This CL fixes this by adding an id to the balloon stats request. The id
is then returned with the computed stats. When consuming stats results
from the balloon_host_tube, we check that the ID is the one we expect,
if not, we keep reading from the tube until we do.
BUG=b:189282316
TEST=tast run dut multivm.Lifecycle.arc_host
Change-Id: I08e50196a45383b30c9e510b3bacbe32888aef80
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3056310
Auto-Submit: Charles William Dick <cwd@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Charles William Dick <cwd@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Hikaru Nishida <hikalium@chromium.org>
Instead of requiring crosvm to be checked out via the chromeos manifest
to access dependencies in the ChromeOS monorepo, this change adds
git submodules to third_party/.
The CI scripts and Cargo.toml are updated to use the new paths.
BUG=b:194336213
TEST=git clone --recursive https://chromium.googlesource.com/chromiumos/platform/crosvm
cd crosvm
cargo test
./test_all
./ci/kokoro/simulate_all
Change-Id: I9859d18176e21909ac3a140976fbd67cc14129bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3049003
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
We need to call Queue::ack_features to actually enable virtqueue specific
features like VIRTIO_RING_F_EVENT_IDX.
BUG=none
TEST=start a vm with a vhost-user block device
Change-Id: I82d04ad940850b53e17cfaf3ee5cdb4318190424
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3070721
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
VIRTIO_IOMMU_F_TOPOLOGY is not needed as DT/VIOT are the preferred
methods for vIOMMU discovery.
BUG=b:181736020
TEST=boot Linux kernel and verify passthru devices work properly with
iommu=on
Change-Id: I07b2924a8a903ccd5def817af6f7e74c8eb91162
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2976056
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Add generate_acpi() to traits PciDevice and VirtioDevice to allow each
device to generate its ACPI table elements. The default implementation
is to generate nothing.
BUG=b:181736020
TEST=boot Linux kernel
Change-Id: I9d8d2cb81d571e608a45e7fecb82c3f0922d0898
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2846423
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
