This removes some unsafe code, improving the interface so that it cannot
be misused (e.g. previously, different Vec<u8> instances could be passed
to fdt functions that did not validate the contents).
The new implementation also adds some extra error checking to catch
invalid string values in all API entry points that accept strings, as
well as out-of-order node nesting that would result in DTB data that did
not conform to the spec.
BUG=b:175729255
TEST=cargo test -p arch
TEST=Boot Crostini on kevin (arm)
TEST=diff old and new dts from `dtc -I fs -O dts /proc/device-tree`
Change-Id: I567d562ed1b447aa0d282b68c71758edea13ffc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2713569
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
- Add an address space region for the protected KVM firmware.
- Query firmware size, mmap something that size and create a memslot.
BUG=b:163789172
TEST=cargo test
Change-Id: I054cf5d763c980d073c17bce70e85a781816b64d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2623942
Auto-Submit: Andrew Walbran <qwandor@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This CL replaces BorrowedIoVec with VolatileSlice, since VolatileSlice
is a superset of the BorrowedIoVec interface. Also uring_mem -> mem
since that interface will not be exclusively used by uring.
BUG=none
TEST=builds
Change-Id: I33e23483e7afc263c76d71f88736cf38fd5e520e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2724863
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
This is a simple python script to uprev ebuild files where Cargo.lock
has a newer version, and vice versa.
The script is run to fix up some libraries that got out of sync.
The protobuf dependencies should be upreved, but newer versions
have deprecated some of the methods we use, causing clippy warnings.
BUG=b:175120466
TEST=Tests in Kokoro and CQ pass
Cq-Depend: chromium:2704533
Change-Id: I1485fbffba61e72502f8398320094dfe2c7ffeea
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2705681
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: kokoro <noreply+kokoro@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
In a long-running system, there is no reason to expect that a
significant number of freed pages are consecutive. However, batching is
relatively simple and can result in significant gains in a newly booted
system, so it's worth attempting.
BUG=None
TEST=arc.Boot.vm
Change-Id: Ia7dff4ab095d640a2a23ac4976bc277b09d9ea79
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2666412
Commit-Queue: David Stevens <stevensd@chromium.org>
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The max values for the multitouch slot ID and tracking/finger IDs were
set to zero previously, making it impossible to track multiple
fingers. This CL updates the max values to allow for 10 MT contact
points.
BUG=None
TEST=applied known working code from another branch.
Change-Id: Ic2e9919c2b83368eb1bc2085122c672fdafbdc84
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2708669
Reviewed-by: Tristan Muntsinger <muntsinger@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Noah Gold <nkgold@google.com>
A BIOS can be larger or smaller than 1 MB; as long as the image is
placed so the reset vector lines up in the correct place at the end of
the 32-bit address space, everything should work.
BUG=b:179053182
TEST=`crosvm run --bios OVMF.fd` and observe debug messages
Change-Id: Ibafd9bb5ee4fd4b0ff2c28c38f022ff3b36dd95d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2651288
Reviewed-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When the file system implements zero message open support, the file
handle is meaningless and it needs to know the inode of the
file/directory on which the ioctl was called.
BUG=b:180565632
TEST=lsattr, chattr, both work when zero message open is enabled.
Android's FileBasedEncryptionPolicyTest[0] gets ENOTTY as an error
instead of EBADF
[0]: bfbc00c20d/tests/tests/security/native/encryption/FileBasedEncryptionPolicyTest.cpp
Change-Id: Ic55ee95df928d645874dd8a9c7dc579b708927fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2706370
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: kokoro <noreply+kokoro@google.com>
Having these function be generic over F: AsRawDescriptor with a &F
parameter means that we cannot use trait objects with them because the
compiler complains that `dyn AsRawDescriptor` does not have a
compile-time size.
Instead change the generic parameter to be a trait object. We're
already doing this in a few other places and we're about to make a
syscall so the cost of dynamic dispatch is probably overshadowed by the
cost of syscall itself.
BUG=b:180565632
TEST=unit tests
Change-Id: I38f696b621411e7cf3e13af71e426865b6509f6f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2706369
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The arm version of libc uses the fcntl64 syscall (0xdd); update the
seccomp policy to match the other arm policies.
BUG=chromium:901139
TEST=Boot Crostini on kevin (arm)
Change-Id: I82eee1ec4918a56495d6c330913c34d4a4a20e4b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2705290
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Handle data offset for input bitstream buffers, as it is sometimes used
to skip headers at the start of buffers.
BUG=b:174531173
TEST=android.media.cts.MediaDrmClearkeyTest#testClearKeyPlaybackMpeg2ts
Change-Id: I6beee5cde24803ba90638c1dc130b75466f4847d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2692676
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Fixes a clippy issue and disables the panic_safe test.
This test occasionally deadlocks (Maybe a 5% chance) when running
inside a test VM. I filed a bug to re-enable it.
BUG=b:179924844
TEST=kokoro passes
Change-Id: I6e9b5fc38e7bbab3fd4b2b8ba8cb5532dd14af7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2697860
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This is the original CL with one minor exception: we don't bind
mount the camera socket with the GPU device. That was the prior
behavior, and for some reason it really doesn't work with Mali +
SECCOMP[1]. It's not really important for the Wayland prototype,
so we'll let the camera team figure it out if and when they are
so inclined.
Bug: b:146066070
Bug: b:173630595
Bug: b:150239451
Bug: b:180126126
TEST=arc.Boot.vm
[1] audit(1613339319.226:43): auid=4294967295 uid=603 gid=603
ses=4294967295 subj=u:r:cros_camera_algo:s0 pid=17107
comm="cros_camera_alg" exe="/usr/bin/cros_camera_algo" sig=31
arch=40000028 syscall=54 compat=1 ip=0xe86a70b8 code=0x0
This reverts commit 51e1c4ad3e3a71a263501d2566d3b1ea59ba2070.
Change-Id: I74f49ece55656d7a9096900e3f19a528234b4224
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2695550
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Robert Tarasov <tutankhamen@chromium.org>
Enable the ZERO_MESSAGE_{OPEN,OPENDIR} features when the cache policy is
"always". This feature allows the kernel to skip the open message after
a successful lookup, reducing the amount of work that the server does.
This is implemented by changing the file descriptors stored in the
InodeData from O_PATH fds to O_RDONLY fds for files and directories.
Other types of directory entries (symlinks, special files, etc) still
use O_PATH fds.
If the kernel sends a write request for an fd opened in read-only mode
or a read request for an fd opened in write-only mode (can happen when
creating a new file), then we open a new fd in read-write mode before
performing the read/write. This only needs to happen the first time we
get a request that doesn't match the open flags.
This change should improve performance of opening and reading many small
files. It improves the blogbench read score by ~40% but reduces the
write score by ~25%. It also reduces the work done by the virtio-fs
server when loading roblox. The first load time is reduced by
~17% (3.04 seconds -> 2.52 seconds) and non-initial load times are
reduced by 50% (0.3 seconds -> 0.15 seconds).
BUG=none
TEST=vm.Virtiofs, vm.Blogbench.virtiofs, arc.PlayStore.vm, load roblox
inside arcvm
Change-Id: I042246a2fd9f7a0feeffc0f629073c594626392a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684066
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
This reverts commit a9c4b3a749.
Reason for revert: This made ARCVM fail to boot on kukui-arc-r. See http://b/180126126.
Original change's description:
> rutabaga_gfx: cross-domain: a new year's miracle in February
>
> The cross-domain context is specialized for cross domain
> allocation/resource sharing. It takes direct inspiration from
> the pioneering virtio_wl device and tries to incorporate
> similiar functionality into virtio_gpu.
>
> The goal here is just to introduce the building blocks so we
> can continue experimenting. In particular, this change:
>
> * hooked up the RutabagaChannels. This is typically a socket to
> Wayland or Mojo for the camera use case.
>
> * added CROSS_DOMAIN_CMD_INIT and CROSS_DOMAIN_CMD_GET_IMAGE_REQS
> to the cross-domain protocol. Further commands (such as
> CROSS_DOMAIN_SEND) will be needed, but that requires more
> Sommelier refactorings.
>
> * added a path to RutabagaGralloc to allocate via minigbm or shared
> memory.
>
> * Recieves responses via a shared ring buffer of type BLOB_MEM_GUEST.
> The synchronization protocol looks positively primitive compared to
> the revolutionary Address Space Graphics (ASG) algorithm [1], but
> it may be sufficient for the Wayland use case.
>
> [1] https://goto.google.com/address-space-graphics
>
> 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: I46784f17040494ce3a646bdbde516800aa64bd5d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626488
> 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>
Bug: b:146066070
Bug: b:173630595
Bug: b:150239451
Bug: b:180126126
Change-Id: Ie33442fdcedcf43b6a24d25198fa2d88b5b96919
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2695056
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Hiroki Sato <hirokisato@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Hiroki Sato <hirokisato@chromium.org>
Commit-Queue: Hiroki Sato <hirokisato@chromium.org>
Commit "1fcc8a8f io_uring: Make UringContext Sync" uncovered an issue
where wakeups were lost if a uring operation was added from a different
thread while the executor thread was blocked inside an io_uring_enter
call. To fix this, PendingOperation calls UringContext::submit
whenever the pending IO is not yet completed and has not been submitted.
Unfortunately, since we tend to write code like
`r.read_to_vec(..).await`, this meant that we would call
UringContext::submit every time after adding a new operation to the
submit queue, kind of defeating the purpose of batching multiple IO ops
in a single syscall. Instead only call UringContext::submit when the
current thread is not the same as the executor thread. The executor
will submit all pending operations anyway the next time it calls
UringContext::wait so there's no need to do it from PendingOperation
when it is polled on the executor thread.
BUG=none
TEST=unit tests
Change-Id: Ia95f3844790d3392e074e3ab55a9c6ef59f29db2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684063
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Destroying a stream while there are outstanding async commands results
in the responses for those commands having no corresponding tracked
descriptor. Instead of trying to handle this case specifically, make
untracked async responses non-fatal errors, instead of shutting down the
decoder device completely.
BUG=b:177697115
TEST=android.security.cts.StagefrightTest
Change-Id: I142ec9814fd69ddb79ef16140b7b06cd0c9f0123
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2690728
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
The newly added async primitives allow for increasing the separation of
the various tasks performed by balloon. Breaking each task in to an
asynchronous function.
BUG=chromium:901139
TEST=Boot crosvm, run 'crosvm balloon' to set the balloon size, check
'vmstat' inside the VM to verify the free memory is affected by the
balloon growing and shrinking.
run crosvm balloon_stats command and ensure that stats are reported
correctly.
Change-Id: I0ae2be5eb8e4be65b2eb74de90888357af6ecfd4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1993163
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The cross-domain context is specialized for cross domain
allocation/resource sharing. It takes direct inspiration from
the pioneering virtio_wl device and tries to incorporate
similiar functionality into virtio_gpu.
The goal here is just to introduce the building blocks so we
can continue experimenting. In particular, this change:
* hooked up the RutabagaChannels. This is typically a socket to
Wayland or Mojo for the camera use case.
* added CROSS_DOMAIN_CMD_INIT and CROSS_DOMAIN_CMD_GET_IMAGE_REQS
to the cross-domain protocol. Further commands (such as
CROSS_DOMAIN_SEND) will be needed, but that requires more
Sommelier refactorings.
* added a path to RutabagaGralloc to allocate via minigbm or shared
memory.
* Recieves responses via a shared ring buffer of type BLOB_MEM_GUEST.
The synchronization protocol looks positively primitive compared to
the revolutionary Address Space Graphics (ASG) algorithm [1], but
it may be sufficient for the Wayland use case.
[1] https://goto.google.com/address-space-graphics
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: I46784f17040494ce3a646bdbde516800aa64bd5d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626488
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>
Only relocating FDT to the front of RAM if booting arm guest in BIOS mode.
ARCVM depends on the kernel and fdt placement at 0x80080000 and the end
of RAM respectively to boot correctly.
BUG=b:177926450
BUG=b:178427080
TEST=local boot of android virtual device on ARM host
Change-Id: I4c23bd2db63532ab3cc478627818322641b895bd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2686590
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Ram Muthiah <rammuthiah@google.com>
Commit-Queue: Ram Muthiah <rammuthiah@google.com>
Auto-Submit: Ram Muthiah <rammuthiah@google.com>
Reviewed-by: Alistair Delva <adelva@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This was based on an unmerged set of kernel patches that have now been
dropped from the chrome os kernel as well. Remove them here.
BUG=none
TEST=cargo test
Change-Id: Id307bb0b51879033ea82c2d360a57752728fbf3e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684065
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
An upcoming mesa-freedreno uprev will require a couple crosvm policy
updates. In particular setscheduler/setaffinity, for the same reasons
that AMD requires them.
BUG=b:179519741
TEST=Start crostini with upstream mesa MR that starts requiring
setscheduler/setaffinity
Change-Id: I4f41a638f413b35f2afebdbe39dde02a02f8322a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2683032
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Rob Clark <robdclark@chromium.org>
Commit-Queue: Rob Clark <robdclark@chromium.org>
Auto-Submit: Rob Clark <robdclark@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This CL fixes some of the issues that prevented the
test system from running on other workstations.
- Builders run by Kokoro will not use a scratch mount.
It's not needed, and will cause issues if stored on
/tmp with noexec set.
- Running podman with label=disable to prevent selinux
issues.
The run_tests implementation has been moved to a separate
file and updated with parsing of cargo test output. This
allows simpler test output and integration with the
test results UI in sponge.
The sponge test UI can make it much easier to see which
tests failed, and to find the log of that test case.
This CL also includes an ./ci/kokoro/uprev script to
uprev the manifest versions. And runs the uprev.
BUG=b:174861002
TEST=Tested by forcing a kokoro build with this CL
Change-Id: I0cba9bb68915e2558a4ea6061dd9ba0a7050421b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2669712
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
From fuse/dev.c in Linux kernel[1], max_write should not include the
headers. Without this fix, the buffer returned by the FUSE device comes
with a header that fails this check.
[1] https://elixir.bootlin.com/linux/v5.11-rc7/source/fs/fuse/dev.c#L1220
BUG=chromium:1176310
TEST=large write succeeds after applying this fix
Change-Id: I321c27a0ca005de6a021bdf044b7d859b57f1cfa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2685219
Tested-by: Victor Hsieh <victorhsieh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Victor Hsieh <victorhsieh@chromium.org>
Allow the caller of config_register_write to determine whether a given
write to PCI configuration space has enabled or disabled the memory or
I/O bits in the command register. This will be used as a signal to
insert or remove a PCI device to/from the corresponding bus.
BUG=b:174705596
TEST=cargo test -p devices
TEST=Manual test with full PCI BAR remapping patch set
Change-Id: I7a3484bd5143d25756c6fdc9f3a8f684db7db8cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2388964
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This adds support for battery charge, voltage, battery charge counter
in power_monitor and populates these fields from powerd data.
BUG=b:162479956
TEST=Compare voltage_now, charge_full, charge_now/charge_counter,
current_now fields in sysfs on host and in ARCVM
TEST=CTS tests android.cts.statsd.atom.HostAtomTests#testBatteryVoltage,
android.cts.statsd.atom.HostAtomTests#testFullBatteryCapacity
and android.cts.statsd.atom.HostAtomTests#testRemainingBatteryCapacity
pass in ARCVM
Change-Id: I3f93f499fa7d00cc5a0a2b69e7cfbcd233a2983a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2681212
Tested-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alex Lau <alexlau@chromium.org>
Use resources allocator to assign or reserve PCI device address.
For pass-through devices it will enable 1:1 mapping to the host BDF.
Transition to address_allocator for pci address and irq allocations.
BUG=None
TEST=build_test && tast run vm.*
Change-Id: I854da9645a305b7b24acb3dd6d851c3486ed23f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2210848
Tested-by: Tomasz Jeznach <tjeznach@chromium.org>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Fixes some nits that cause kokoro builds to fail and updates
the Kokoro configs to match the new Kokoro-side configs
submitted in cl/355894530.
With this CL Kokoro v2 should be passing and can be enabled as
a presubmit.
BUG=b:179289824
TEST=Kokoro passes
Change-Id: I8c9259407bf1eb932b05376b35cb88d2e7d6058c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2678792
Tested-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Should fix the following error:
---- rutabaga_gralloc::gralloc::tests::create_render_target stdout ----
thread 'main' panicked at 'called `Result::unwrap()` on an `Err`
value: Unsupported', rutabaga_gfx/src/rutabaga_gralloc/gralloc.rs:314:64
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
BUG=b:173630595
TEST=cargo test locally
Change-Id: Ieb24166f3975d4d7c99c08a3d0824ee64668c93e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2675231
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Adds the crosvm-side infrastructure to build and test
in kokoro.
There is a build script for testing on x86, aarch64
and a separte script for analysis (clippy, fmt).
These will run in parallel on Kokoro. To test the
scripts locally, a simulate script is provided.
Runtime on my workstation:
- aarch64: 10m
- x86: 2:30m
- analysis: 1:40m
BUG=b:177951955
TEST=./ci/kokoro/simulate_all
Change-Id: I2f666ec768e6c3391a258dc7f0cbd999ad9b2fb1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2654413
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The VM allows both the x86 and aarch64 builders to run tests which
require access to kernel devices that docker would prevent us
from accessing.
The VM is automatically started in the endpoint script, and the
environment is set up to execute `cargo test` binaries inside the VM.
This allows for convenient interactive usage.
The VM is also integrated into the run_tests scripts, executing tests
that do not require special privileges first, while the VM is still
booting up, then execuing the remaining tests in the VM.
BUG=b:177228167,b:177951276
TEST=These test calls pass:
./ci/builder --vm ./run_tests
./ci/aarch64_builder --vm ./run_tests
./run_tests
Change-Id: I20bf2cd848e944d411b97f1f8356279e312d8583
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2642766
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
When building without the "audio" feature, an import of virtio::snd in
pci_device failed to compile; wrap it in a feature check to fix this.
This fixes the crosvm fuzzer build.
BUG=chromium:1174254
TEST=cargo build --no-default-features
TEST=build crosvm with amd64-generic asan profile
Change-Id: Iecd549c313d6210ee90e9e405c02a9e7581e1141
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2674260
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
rutabaga_gralloc is a cross-platform, Rust-based buffer
manager.
The rationale for this change is:
1) For the {cross-domain, wayland} context type, we need to
have a good story for the crucial "wl-dmabuf" feature. As
minigbm has been thoroughly tested on ChromeOS and currently
powers the "wl-dmabuf" feature, it only makes sense for us to
have a path to minigbm for the cross-domain prototype. This
will be used by Sommelier.
2) While minigbm allocation works well on Chromebooks, it is
not sufficient for cross-platform purposes. For their Virtual
Graphics Interface (VGI) initiative, Android graphics
virtualization experts have expressed their desire for a Vulkan
based allocator. This will to go alongside cros_gralloc in
minigbm, which is considered by many to be the ""world's
premiere gralloc implementation".
3) Android graphics virtualization experts have expressed their
desire for vkMapMemory(..) to be used when crosvm is in
multi-process mode. Currently, only dma-buf mmap() is supported
for zero-copy blobs in multi-process mode. dma-buf mmap() is not
guaranteed to work on Nvidia (a "must have" for Cuttlefish) or
any other driver for that matter (we *make* it work for ChromeOS).
Possibly only solution: vkMapMemory ;-)
With these goals in mind, here's a summary of the revelant changes:
* Renamed the {gpu_allocator.rs, GpuMemoryAllocator trait} to be
{gralloc.rs, Gralloc trait}.
* Moved all GPU allocation out of the resources crate and into
the rutabaga_gfx crate. This will allow the resources crate to
be focused on managing resources for virtual machines.
* Moved the gpu_buffer crate into the gralloc module in the
rutabaga_gfx crate. The same functionality is now under
"minigbm.rs", "minigbm_bindings.rs" and "rendernode.rs"
* Added an optional dependency on vulkano.rs. vulkano.rs is a safe
Rust wrapper around the Vulkan api [a]. It's emphasis on type
safety makes a good fit for crosvm, though there are other high
quality crates out there (gfx-rs, ash.rs). Though development
has slowed down, it should satisfy goals (2) and (3) quite easily.
* Added a system_gralloc implementation based on memfd. This can be
used when minigbm or Vulkano features are not used, to replicate the
highly useful "wl-shm" feature in Sommelier. Astute observers will
note this can also enable seamless Wayland windowing without GPU
features for Android too. Some minor changes to the base crate were
needed.
* Cut down on the amount of DrmFormats to the subset needed by
Sommelier and cros_gralloc.
* Moved checked arithmetic into it's own file.
* Internally renamed to "wl-dmabuf" feature to be the "minigbm"
feature. This is because "wl-dmabuf" has a dependency on minigbm.
* Small rutabaga_gfx cleanups
[a] https://github.com/vulkano-rs/vulkano/blob/master/DESIGN.md
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=run sommelier with "wl-dmabuf" and "wl-shm"
Change-Id: I693a39cef64cd98e56d843d3c60caa7983d4d6e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626487
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Offset right now means the offset from base address that the
device was accessed at. And address is the absolute address
of the device's access in its address space. The port 0x61 and
0x64 is the absolute port number.
BUG=None
TEST=boot VM and run reboot command
Change-Id: I51ee90e51b559254cf76f2bec4d174294961fe1c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2648858
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Alistair Delva <adelva@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Alistair Delva <adelva@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
The arcvm guest has been observed to fail early in boot with a low
probability; the root cause seems to be a missing interrupt from the
virtio-block device causing the guest to wait forever for a notification
that does not happen.
In testing, it seems that ignoring the VIRTQ_AVAIL_F_NO_INTERRUPT flag
set by the guest avoids the issue; possibly there is a race in the
publishing of used descriptors versus the checking of this flag, but I
was not able to find a definitive solution.
Ignoring the flag means that we may occasionally trigger an interrupt
when the guest has indicated that one is not necessary; this is, at
worst, a slight performance degradation, not a correctness issue, since
the guest kernel will ignore spurious interrupts.
BUG=b:172975852
TEST=Restart arcvm in a loop without failures 1000+ iterations
Change-Id: I4c91ccc5dadc03dde43008ff20fae1c4592e19da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2648009
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This reverts commit 890ae4cdb8.
Reason for revert: breaks arc.Boot.vm on kukui-arc-r
Original change's description:
> Relocate FDT to beginning of RAM
>
> This change serves two purposes. The FDT needs to be in a location
> accessible by 32 bit devices. Secondly the FDT's location was dependent
> on the amount of RAM allocated to the guest prior to this change which
> made passing it's location to the BIOS challenging.
>
> By moving the FDT to a fixed location within the 32 bit accesible memory
> boundary, these problems have been fixed.
>
> BUG=b:177926450
> TEST=local boot of android virtual device on ARM host
> Change-Id: I89e481f66ddc8ffcf0e86f00fbfa92d407c48736
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2641126
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Tested-by: Ram Muthiah <rammuthiah@google.com>
> Commit-Queue: Ram Muthiah <rammuthiah@google.com>
Bug: b:177926450
Bug: b:178427080
Change-Id: Iba629542d024fff84721ff434655c0c322020db3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2656215
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Ryo Hashimoto <hashimoto@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Ryo Hashimoto <hashimoto@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
These will eventually be used when the virtio-snd device is
implemented as well as by the VioS audio backend.
BUG=b/174713663
Change-Id: Id9fe1527a128df0059805076c01e20ddb1ad2b72
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574812
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Closing the uring fd should release the resources borrowed by the kernel
so there's no reason to call io_uring_enter to drive any pending IO to
completion. Doing so may end up blocking the thread indefinitely.
Instead just make sure that the URingContext is dropped before anything
else. Rust's drop order guarantees that struct fields are dropped in
the order of declaration so this just means putting it first.
Also, since the RawExecutor is wrapped in an Arc it may end up being
dropped from a different thread than the one that called run() or
run_until(). We know there are no other references so just clear the
cached thread_id so that we don't panic in the drop impl. We don't
currently have any users that want to run the executor concurrently on
multiple threads so we'll just punt that problem until we actually need
to deal with it.
BUG=none
TEST=unit tests
Change-Id: Icf6a23fc433128dd00adbd56a715dbae24cd8ea2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643845
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
IORING_OP_NOP is a no-op that does no IO and can be used to measure the
performance of the io_uring subsystem or to wake up a thread currently
blocked inside an io_uring_enter syscall. Use it instead of keeping a
separate eventfd.
BUG=none
TEST=unit tests
Change-Id: I3b3e93c653e1db747c90456c1d93abb979c25d34
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643844
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Rather than requiring callers to wrap the entire UringContext in a big
lock, make UringContext Sync by internally using fine-grained locks:
* The submit queue is wrapped with a Mutex so that threads may still add
operations to the submit queue even when a thread is blocked
inside an io_uring_enter call.
* The completion queue internally uses a Mutex around the pending op
data and completed count so that two threads don't end up trying to
remove the same operation from the completed queue.
With this we can enable the await_uring_from_poll test. This test
uncovered missing wakeups in the case where a uring operation is added
from one thread while the main uring thread is blocked inside an
io_uring_enter syscall. To deal with this, we call submit() whenever the
pending operation is polled and not yet submitted.
BUG=none
TEST=unit tests
Change-Id: I4c7dec65c03b7b10014f4a84d2cd16fe8758ea72
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643842
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This is like future::task::ArcWake but uses Weak<T> instead of Arc<T>.
This prevents a circular reference where the RunnableQueue would hold an
active reference to the executor (via its waker) while the executor
owned the RunnableQueue, leading to memory leaks.
With this the executor should only be using weak references internally
and the only strong references should be in the public *Executor type.
Also fix the tests that were broken by this change.
BUG=none
TEST=unit tests
Change-Id: I3e9c007d533e154b2ad9d1e4d56a692f65da6aa0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643841
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
There are a lot of changes in this one but these are the high-level
points:
* Both executors now support non-fd futures and it's now possible to
start a poll operation on one thread and then await the result inside
a UringExecutor on another thread. The reverse doesn't work yet but
will once we make UringContext sync.
* A few layers of indirection have been removed so hopefully both the
implementation and the interface are simpler.
* The thread local magic is gone in favor of directly calling methods on
an executor. Executor handles can be cheaply cloned to make this
easier.
* Heap allocations are limited to the spawn and spawn_local methods so
it's possible to completely avoid heap allocations if callers only use
the run_until method.
* The IoSource, Executor, FutureList traits are gone.
BUG=none
TEST=unit tests
Cq-Depend: chromium:2629068
Change-Id: I86053007929c36da66f3b2499cdefce0b5e9a180
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2571401
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
