Checking the state with a relaxed load before doing a
compare_exchange_weak can reduce unnecessary coherence traffic on the
CPU and improve performance.
BUG=none
TEST=unit tests
Change-Id: Icabd9863ceb5ba674dbec601afee8f7962f69413
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2805753
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Drop order in rust is weird. Temporaries created in an if let
expression are dropped _after_ the else branch. In this case that meant
we were sleeping while holding the spin lock, which could potentially
lead to the test hanging ~forever if the thread trying to update the
value repeatedly failed to acquire the lock.
Move the sleep out of the else branch so that the lock is dropped after
checking for the waiter but before the thread goes to sleep.
BUG=none
TEST=Run unit tests and see that they no longer get randomly stuck for
several seconds.
Change-Id: I08aa80169071959593bee157acda39411472cf11
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2804870
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
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>
Convert the pub member to private and provide an accessor.
Prevents the spread of poking in to a private member from vhost.
Change-Id: Ib2070e990dc91c532164cc83f5af72bfbc9b2e89
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2795283
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Updating an atomic value invalidates the entire cache line to which it
belongs, which can make the next access to that cache line slower on
other CPU cores. This can lead to "destructive interference" or "false
sharing", where atomic operations on two or more unrelated values on the
same cache line cause hardware interference with each other, reducing
overall performance.
Deal with this by aligning atomic primitives to the cache line width so
that two primitives are not placed on the same cache line. This also
has the benefit of causing *constructive* interference between the
atomic value and the data it protects. Since the user of the atomic
primitive likely wants to access the protected data after acquiring
access, having them both on the same cache line makes the subsequent
access to the data faster.
A common pattern for synchronization primitives is to put them inside an
Arc. However, if the primitive did not specify cache line alignment then
both the atomic reference count and the atomic state could end up on the
same cache line. In this case, changing the reference count of the
primitive would cause destructive interference with its operation. With
the proper alignment, both the atomic state and the reference count end
up on different cache lines so there would be no interference between
them.
Since we can't query the cache line width of the target machine at build
time, we pessimistically use an alignment of 128 bytes based on the
following observations:
* On x86, the cache line is usually 64 bytes. However, on Intel cpus the
spatial prefetcher "strives to complete every cache line fetched to
the L2 cache with the pair line that completes it to a 128-byte
aligned chunk" (section 2.3.5.4 of [1]). So to avoid destructive
interference we need to align on every pair of cache lines.
* On ARM, both cortex A-15 (armv7 [2]) and cortex A-77 (aarch64 [3])
have 64-byte data cache lines. However, Qualcomm Snapdragon CPUs can
have 128-byte data cache lines [4]. Since Chrome OS code compiled for
armv7 can still run on aarch64 cpus with 128-byte cache lines assume
we need 128-byte alignment there as well.
[1]: https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
[2]: https://developer.arm.com/documentation/ddi0438/d/Level-2-Memory-System/About-the-L2-memory-system
[3]: https://developer.arm.com/documentation/101111/0101/functional-description/level-2-memory-system/about-the-l2-memory-system
[4]: https://www.7-cpu.com/cpu/Snapdragon.html
BUG=none
TEST=unit tests
Change-Id: Iaf6a29ad0d35411c70fd0e833cc6a49eda029bbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2804869
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Now that we're not transferring waiters between the Condvar and the
Mutex we can simplify how the cancel function works. Also, now that it
never changes we can drop the Spinlock around it and treat it like a
const field.
BUG=none
TEST=Run unit tests in a loop on both x86 and arm and observe no
failures or hangs
Change-Id: I0851c4eeb0b9462098ed1ac186a25f1c5791511a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2804868
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
A performance optimization should never change the observable behavior
and yet that's what this one did. Canceling a `cv.wait()` call after
the waiter was already transferred to the Mutex's wait list should still
result in us waking up the next waiter in the Condvar's wait list.
Instead, the `cancel_after_transfer` test was checking for the opposite
behavior.
Additionally, the transfer was racy with concurrent cancellation.
Consider the following sequence of events:
Thread A Thread B
-------- --------
drop WaitFuture cv.notify_all()
waiter.cancel.lock() raw_mutex.transfer_waiters()
c = cancel.c
data = cancel.data
waiter.cancel.unlock()
waiter.cancel.lock()
cancel.c = mu_cancel_waiter
cancel.data = mutex_ptr
waiter.cancel.unlock()
waiter.is_waiting_for = Mutex
mu.unlock_slow()
get_wake_list()
waiter.is_waiting_for = None
waiter.wake()
c(data, waiter, false)
cancel_waiter(cv, waiter, false)
waiter.is_waiting_for == None
get_wake_list
There are 2 issues in the above sequence:
1. Thread A has stale information about the state of the waiter. Since
the waiter was woken, it needs to set `wake_next` in the cancel
function to true but instead incorrectly sets it to false. By
itself, this isn't that big of an issue because the cancel function
also checks if the waiter was already removed from the wait
list (i.e., it was woken up) but that check is problematic because of
the next issue.
2. The Condvar's cancel function can detect when a waiter has been moved
to the Mutex's wait list (waiter.is_waiting_for == Mutex) and can
request to retry the cancellation. However, when
waiter.is_waiting_for == None (which means it was removed from the
wait list), it doesn't know whether the waiter was woken up from the
Mutex's wait list or the Condvar's wait list. It incorrectly assumes
that the waiter was in the Condvar's wait list and does not retry the
cancel. As a result, the Mutex's cancel function is never called,
which means any waiters still in the Mutex's wait list will never get
woken up.
I haven't been able to come up with a way to fix these issues without
making everything way more complicated so for now let's just drop the
transfer optimization.
The initial motivation for this optimization was to avoid having to make
a FUTEX_WAKE syscall for every thread that needs to be woken up and to
avoid a thundering herd problem where the newly woken up threads all
cause a bunch of contention on the mutex. However, waking up futures
tends to be cheaper than waking up a whole thread. If no executor
threads are blocked then it doesn't even involve making a syscall as the
executor will simply add the future to its ready list. Additionally,
it's unlikely that multi-threaded executors will have more threads than
the # of cpus on the system so that should also reduce the amount of
contention on the mutex.
If this code starts showing up as a hotspot in perf traces then we
should consider figuring out a way to re-enable this optimization.
BUG=chromium:1157860
TEST=unit tests. Also run the tests in a loop for an hour on a kukui
and see that it didn't hang
Cq-Depend: chromium:2793844
Change-Id: Iee3861a40c8d9a45d3a01863d804efc82d4467ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2804867
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Allowing each region to have a separate backing FD will make it possible
to build GuestMemory from the vhost `SET_MEM_TABLE` message that
transmits the memory regions for virtio queues in vhost-user devices.
Change-Id: I6f9bc6136915da9d873ea896823e3b8f426ca69d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2795282
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Create the virtio video-decoder and video-encoder devices after the GPU
device so that the device number of GPU will be consistent on ARCVM
platforms where video devices may or may not exist.
BUG=b:178348623
TEST=boot arcvm on betty and hatch, check gpu pci id is equal
Change-Id: I99d9d0befe6e5aea16fc4e85ed527e4954010466
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2773655
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
A new background thread is added to the client to receive buffer
status messages from the server. The VioSClient struct is made thread
safe and can now be kept inside an Arc instead of a Mutex.
BUG=b/163867676
Change-Id: I52c6d93d36096699906dfc95821dc1834ff6f7bd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2795292
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@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>
Now that msg_socket is no longer used anywhere, remove the code so that
nobody else starts to use it. Use serde and tube instead.
TEST=run_tests
BUG=b:176847362
Change-Id: Ibe68b47b444830a921d6ba98798dfc163447d31b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2722915
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Add magic comments so that we can have separate ebuilds for the io_uring
and cros_async crates.
BUG=none
TEST=`FEATURES=test emerge-$BOARD cros_async`
Change-Id: I8e4befc90d44b4b021864f4358c8f9b3ec5a87d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2794162
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
Tube is the replacement for MsgSocket and related types and traits.
TEST=run_tests
BUG=b:176847362
Change-Id: I290279a714eb04c5cc6f2aef15ba7c61c708ab08
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2726980
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Option: --vhost-user-fs "$SOCKET_PATH:$TAG"
BUG=b:181190800
TEST=Interoperability test with virtiofsd-rs
TEST=Run pjdfstest in the shared dir added by --vhost-user-fs
TEST=Mount 2 different virtio-fs devices at the same time
TEST=Boot from a virtio-fs device directly with
"root=/dev/root rootfstype=virtiofs"
Change-Id: Id4bbcccc89d7d0d84fd5f5603c3af5576f02522f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2690735
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Woody Chow <woodychow@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Doing this in the init() function means that this bit only gets set for
the worker thread that handles the init message. Instead do this in
Worker::run so that it gets set for all worker threads.
BUG=none
TEST=vm.Virtiofs
Change-Id: I9b2dc309e3cc2d26a6250cbe8c3bd7409dbb2e5a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2794161
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Kernel interface to the host interrupt passthrough driver.
User space part of the interrupt handler registers eventfd
objects for trigger notifications and interrupt resample
requests.
BUG=b:173824544
TEST=None
Change-Id: I1b8f443655e7232e668c7d3bea78fbebf150e169
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2733580
Tested-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Support for the VIRTIO_BLK_T_GET_ID operation was added to the non-async
block device while the async block device was under development and not
yet merged. Add support for GET_ID to async block to fix the feature
gap.
BUG=chromium:901139
TEST=Launch crosvm with async disk with id
TEST=cat /sys/block/vda/serial
TEST=cargo test -p devices
Change-Id: I329359b9c4dc459ebcf5846ac5307f56192ce02e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2792681
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Hello everyone ..! After 2.5 years of "on the side" inquiries,
I have finally completed my investigations [1] of the udmabuf!!
udmabuf is a kernel driver that turns memfd pages into dmabufs.
The original hope was it would reduce texture upload costs for
virgl, which it did for larger textures [2]. But no measurable
improvements where seen with real games. In addition, a more
advanced "gfx-streaming" model has since come into the horizon[3][4],
which is more performant, conformant, secure and simpler than
virgl. As such, building more on virgl does not seem to be best
option, but that's another story for another day.
Where does that leave udmabuf, then?!? The investigation was
able to turn up two possible use cases:
1) Intel integrated + dGPU PCI-passthrough resource sharing
When the dGPU is passthroughed into the guest, the dGPU's memory
is not available to the host. Ideally, for zero-copy, we would
like to get the render target out of the guest somehow and then
send to the display. Many approaches have been proposed, such
as Vivek Kasireddy's Vdmabuf driver [5]. The current thinking
is virtgpu guest blobs can be exported, and then imported into
the dGPU -- Vivek is looking into this approach right now ..!!
Sommelier or virtgpu KMS can then share the guest blob with the
host. It's a quite complex use case and requires changes to guest
Mesa GBM to get (such as metadata query) to get the right modifier.
Indeed, some would even say you need a virtgpu context type optimized
for sharing across domain boundaries. minigbm already supports this
for Android upstream's Virtual Graphics Interface (VGI) initiative.
2) Guest VRAM dedicated heap created udmabufs
This use case, proposed by automative virtualization expert Dmitry
Sepp [6], is primarily for automotive hypervisors (such COQOS).
It's typically not easy for such hypervisors to get zero-copy via
BLOB_MEM_HOST3D, and these hypervisors have had their homebrew
versions of udmabuf for many years. It's important to upstream the
workarounds that are currently done for such hypervisors. To increase
security and isolation, a guest dedicated heap is preferred over guest
system memory. We might even need dedicated queues, who knows.
crosvm seems like the most likely upstream target due to it's world
class blob support and open-source nature. As such, this CL adds basic
udmabuf capabilites so these use cases can be developed further via
crosvm.
[1] https://www.youtube.com/watch?v=lp6z3s1Gig0
[2] crrev.com/c/1325515
[3] goto.google.com/address-space-graphics
[4] https://drive.google.com/file/d/19K_6M8QUeOn-x7HVYvoNfnuC6G5vkR8f/view
[5] https://lists.freedesktop.org/archives/dri-devel/2021-February/296177.html
[6] https://gitlab.freedesktop.org/virgl/virglrenderer/-/issues/159
BUG=chromium:892806, b:173630595
TEST=Create a bunch of udmabufs from the guest, with the subsequent
patches
Change-Id: Ia8083c0aa065f303f660ec6875ff5fb76f5d7b4f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786290
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Useful for the udmabuf use case. The current offset used
by the callback is relative to the mapping, not the absolute
memfd offset.
BUG=chromium:892806, b:173630595
TEST=cargo test -p vm_memory
Change-Id: I57d02d016888a2d974f1f9e359375cb0941dc949
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786289
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@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>
Allow:
- UDMABUF_CREATE_LIST -- needed to create udmabuf
- DMA_BUF_IOCTL_SYNC -- to flush the udmabuf.
virtio-wl already allows this everywhere so
this should be fine.
Also add the path to minijail.
BUG=chromium:892806, b:173630595
TEST=no sandbox violations
Change-Id: I70ace6ef0349c4b133615eb41f9f56ccd7121e4b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786287
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
dverkamp@ suggested that crrev.com/c/1157440 contained a
mis-reading of the relevant Wikipedia article.
BUG=chromium:892806, b:173630595
TEST=boot VM with capabilities list of size 207
Change-Id: I4afbe2058b5439bc502be59b8063a4db0fc5a12b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2792041
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
This CL reverts previous attempts at reducing the flakiness of the test
and disables it completely.
BUG=b:183722981
TEST=./test_all
Change-Id: I36527d6404c67ff9e73792676a52f064d2f48d14
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2787246
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This refactors register_signal_handler to take a callback with the
correct parameter (c_int).
It adds functionality for clearing signal handlers, checking if a signal
handler is defined, and waiting for a signal. As part of this work a
helper function was added to create libc::timespec structs from
std::time::Duration, and get the max Duration that can be represented by
libc::timespec.
BUG=None
TEST=cargo test
Cq-Depend: chromium:2782855, chromium:2782856
Change-Id: Id531d9aaeeeb65f0f6f9b64bed4aba024a2328cb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2783043
Tested-by: Allen Webb <allenwebb@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Allen Webb <allenwebb@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
These types make up parts of larger messages that implemented
MsgOnSocket.
BUG=b:176847362
TEST=run_tests
Change-Id: I1f99e08f494d646ad0566eb556e2c28726d1d217
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2733207
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This CL enables serde based serialize and deserialize types to interact
with a side-channel stash of descriptors. The idea is that many types
could implement Serialize and Deserialize, but they have descriptors
buried in them, such as a File or kernel object. Although these can be
serialized literally, usually the transciever of the serialized value
needs explicit access to the descriptors to send them over, such as with
Unix domain sockets.
TEST=cargo test -p base
BUG=b:176847362
Cq-Depend: chromium:2757675
Change-Id: I3273889f8d43cca761a54c531a981b7ab1ad3c03
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2576633
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Probably should have been done in the change that added the fuzz crate
to the workspace to prevent the Cargo.lock changes from ending up in
unrelated commits.
BUG=None
TEST=cargo check
Change-Id: I20d42e5b53f24a73c3c351a5dc38eb2a24e8c4eb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2785600
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@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>
Previously we restricted the virtio_input_event/input_event's value
field to u32. In actuality, this field is an i32 in the kernel, and the
negative values are used for relative mice (among other things). This CL
switches the value field to be signed.
BUG=None
TEST=builds (also tested on another branch)
Change-Id: Ia2c43e1a8ee21aa618d97b308369ab49c194cab4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2770724
Auto-Submit: Noah Gold <nkgold@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
These didn't get moved in the original move of cros_async::sync. This CL
adds them.
BUG=None
TEST=builds
Change-Id: I08204a9aedd960e0e8e7befc930076df065b74ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2776214
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
To be truly OS-agnostic, we need an OS-agnostic Rust wrapper over
the OS-specific handle type. SafeDescriptor seems to be the best
option, and I hope it on crates.io in the future.
This converts virtio_gpu/rutabaga to use the SafeDescriptor handle
when practical. minigbm still uses File in some places, since it
needs to SeekFrom(..), but minigbm is a Linux only thing anyways.
BUG=b:173630595
TEST=boot VM in 2D/3D mode
Change-Id: I18d735844d479f52d82d7976bf9b4e383b2e2252
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2779492
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Michael Hoyle <mikehoyle@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
It's still flaky, removing another check. That should take care of it.
Unfortunately it does not reproduce frequently when running locally.
BUG=None
TEST=./test_all
Change-Id: Ie60fef676f860f5ff36f7b0b57ce8582f03fe669
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2774938
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Some judgement calls were made about unnecessary wrapping. Usually they
would get resolved by removing the wrapping or returning a convenient
error, but the ones that returned results for consistency with other
functions were added to the allow list.
The error handling in the usb code had a lot of unit error types which
is now a clippy lint. This was resolved by either removing the result
entirely or returning a convenient error.
The field_reassign_with_default lint is faulty and was added to the list
of supressions. This affected virtio-wayland code.
BUG=b:179277332
TEST=cargo clippy with rustc 1.50+
Change-Id: Ie812cdeaf7c42f4f2b47b1dc87f05a7c87a60f8f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757510
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
glibc 2.32 is using clock_gettime/64 on some arm boards
when gettimeofday is used. In addition, support 64-bit
variants of the time syscalls for use with glibc 2.32.
BUG=chromium:1190305
TEST=crostini tests pass
Change-Id: I070eee92817d3f959ea385ff2c3adca610e0a574
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2776211
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Instead of instanciating crosvm directly, we can start the binary as
a sub-process.
This includes parsing of crosvm options in the tests, and makes the
test cases closer to real-world usage.
To make make this possible, we need to make sure that the crosvm binary
is uploaded to the VM before running the test, which is done by the
sync_so script, which is baked into the builder container.
We prevent future container re-builds for just maintaining the script,
I have removed them from the container, and call the scripts from the
local source directly.
The test runner is also updated to ensure all package binaries are
built (currently only tests are built).
BUG=b:182841358
TEST=./test_all passes
Change-Id: I7dfd21abcb2b90fe125eb43f85572fbf645b888a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2744280
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
For some PCI device, its MMIO bar size may not be page size aligned.
When setting user memory region for such bar with not aligned size, KVM
will report failure back and failed to map that bar. As current crosvm
can continue run with this failure, the performance will be hurt as each
time when guest is accessing this bar, it will trap to hypervisor.
To resolve this, extend the size to be page size aligned when setting
user memory region in KVM and do DMA map. This should be safe to extend
because the mmap actually rounds up the mmap size to be page aligned.
BUG=None
TEST=boot vm with a passthrough device whose bar has unaligned size
Change-Id: Ic816984ec503edf7f12da4893b78d996ebf93976
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2717448
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
