The pointer passed to the kernel for the iovecs must remain valid until
the operation completes. This is true even if the kernel copies the sqe
containing the pointer, that isn't a deep copy. If the iovecs are freed
before the kernel actually processes the op, it will fail with a bad
address error.
Move the responsibility for maintaining the list in memory from the
caller to io_uring itself. This mean io_uring must allocate. Taking
iterators for IoSlice/IoSliceMut, means that the caller doesn't need to
allocate as well if there isn't a Vec already allocated.
Change-Id: I63a009d8ab543c8bac4132809fb851536d4ad82c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2227082
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
This trait handles the x86-specific features of an irqchip, including
getting and setting the state of the pic, ioapic, lapics, and pit.
Also includes an empty implementation of this trait for the
KvmKernelIrqChip.
BUG=chromium:1077058
TEST=cargo test -p devices
Change-Id: I36034661f4a2baedc7ac2b8f311cab6327afefba
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2197717
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
When creating a file or directory the virtio-fs server changes its
effective uid and gid to the uid and gid of the process that made the
call. This ensures that the file or directory has the correct owner and
group when it is created and also serves as an access check to ensure
that the process that made the call has permission to modify the parent
directory.
However, this causes an EACCES error when the following conditions are
met:
* The parent directory has g+rw permissions with gid A
* The process has gid B but has A in its list of supplementary groups
In this case the fuse context only contains gid B, which doesn't have
permission to modify the parent directory.
Unfortunately there's no way for us to detect this on the server side so
instead we just have to rely on the permission checks carried out by the
kernel driver. If the server receives a create call, then assume that
the kernel has verified that the process is allowed to create that
file/directory and just create it without changing the server thread's
uid and gid.
Additionally, in order to ensure that a newly created file appears
atomically in the parent directory with the proper owner and group,
change the create implementation to use `O_TMPFILE` and `linkat` as
described in the open(2) manpage. There is no `O_TMPFILE` equivalent
for directories so create a "hidden" directory with a randomly generated
name, modify the uid/gid and mode, and then rename it into place.
BUG=b:156696212
TEST=tast run $DUT vm.Virtiofs
TEST=Create a test directory with group wayland and permissions g+rw.
Then run `su -s /bin/bash -c 'touch ${dir}/foo' - crosvm` and
`su -s /bin/bash -c 'mkdir ${dir}/bar' - crosvm`.
Change-Id: If5fbcb1b011664c7c1ac29542a2f90d129c34962
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2217534
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Now that the ioctl number method is const we can use a match statement
rather than a series of if-else expressions.
BUG=b:157189438
TEST=unit tests
Change-Id: I9839f2de842ec512811101c07445ca5f99f3fe2f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2214963
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
This allows us to define const variables that are the return value of
the method, which we can then use in match statements.
BUG=b:157189438
TEST=unit tests
Change-Id: I2475c59bfd43ec9ec149a6b688bf680fa2361a0b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2214962
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
These container types are similar to arrays except tuples have
heterogeneous data types and Vec has a dynamic number of elements.
BUG=None
TEST=cargo test -p msg_socket
Change-Id: I2cbbaeb7f13b7700294ac50751530510098ba16d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2168588
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
The clock functions on the Vm trait are for any arch, to support
hypervisors that might have ARM pv clocks. The KVM implementation (x86
only) is mostly the same as before, but uses a hypervisor-agnostic
ClockState struct instead of the KVM struct.
BUG=chromium:1077058
TEST=cargo test -p hypervisor
Change-Id: I0e77ae997d6a30851d28aeb5f73c9ef8ebc464a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2202742
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Steven Richman <srichman@google.com>
Enable support for user provided ACPI tables with supplementary system
description. Argument --acpi-table shall point to exsting file or
pseudo-file with valid ACPI table content.
BUG=None
TEST=boot Linux kernel with generated SSDT tables.
Change-Id: I8eac21da070dcc325884ed888cc7bcb01bc086ce
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2212501
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Tomasz Jeznach <tjeznach@chromium.org>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
The Error type is not used, remove it.
Change-Id: Ibcc1328b62635dd62a666412eb0f56a8c2f4fc93
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2224013
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Support for address_allocator by-alloc release.
Address regions coalescing is performed at the
release time.
BUG=None
TEST=cargo test -p resources && tast test vm.*
Change-Id: Ibd39dac923d1b2f8b6a711d2a9fcbb662fc95bdc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2209171
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
When opening the same output file for two serial devices (earlycon and
console), the output would be overwritten by the later device.
Change the file creation to use append mode so that the output file
contains all of the logs from both devices instead of overwriting it.
Tested with:
crosvm run \
--serial hardware=serial,type=file,console=false,earlycon=true,path=test.log \
--serial hardware=virtio-console,type=file,console=true,stdin=true,path=test.log \
vm_kernel
BUG=None
TEST=see above - verify log contains earlycon and console output
Change-Id: I14dab9eaf56dbb0ae410215324b20b34fea723ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2208712
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Hypervisor-agnostic structures for the pic, ioapic, lapic, and pit.
These are derived from existing structures in the pic, ioapic, and pit
implementations, as well as from the kvm_sys bindings.
Includes From implementations converting these structures to their
associated KVM structures. Also includes tests for these conversion
implementations.
BUG=chromium:1077058
TEST=added tests to convert kvm structures to hypervisor-agnostic
structures
Change-Id: Ie2f254bf2dba3aed755008296c00cb6a49f845fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2197716
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The original stated purpose of this trait was to reduce memory
allocations but having the `into_iovec` method return a Vec kind of
defeats that purpose.
Refactor the trait so that it can either convert a T into an iovec or
convert a &[T] into a &[iovec]. Implement the trait for VolatileSlice,
IoSlice, and IoSliceMut and update all the callers.
BUG=none
TEST=unit tests
Cq-Depend: chromium:2210272
Change-Id: I9d0d617a23030d241d50411f4a5a16e7cba4bcee
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2208527
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Validate that the toggle_cycle code works as expected.
I initially misunderstood the behavior of toggle_cycle in the Link TRB,
but it appears to work correctly as written after writing a unit test to
verify my understanding. Add the unit test anyway to be sure the
behavior doesn't regress in the future.
BUG=None
TEST=cargo test -p devices
Change-Id: I9dbc34b26225945fa6d31c34261f53d5b64ba259
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2199956
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add the missing '?' to check the result of the newly-added
property_string call to match the rest in this function.
Fixes clippy warning about an unused result.
BUG=None
TEST=docker/wrapped_smoke_test.sh
Change-Id: I428b377e1a4f15e0ee96c8e96540f2fc8edce560
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2216400
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The VolatileSlice API changed, but some callers were not updated to
match. Fix them up so that builds with additional features enabled
(e.g. kokoro) pass again.
BUG=None
TEST=cargo test -p disk --features=composite-disk
TEST=docker/wrapped_smoke_test.sh
Change-Id: I97b3cd04549af30b7dc1515245f025d9439669bc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2216399
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Support for address range allocation at specific
location and size. Allocation is successful only
if requested range is available and free.
Change to address_allocator allocation algorithm
from contiguous memory allocation to first-fit like
implementation to allow memory release/reuse in future.
BUG=None
TEST=cargo test -p resources && tast test vm.*
Change-Id: I58218f5a2c6a215152904cc1cf0748e842fa7374
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2203297
Tested-by: Tomasz Jeznach <tjeznach@chromium.org>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Change VolatileSlice so that it is ABI-compatible with iovec. This
allows us to directly pass in a VolatileSlice for a C function that
expects an iovec without having to create temporaries that convert from
one to the other.
Also change all the parameters from u64 to usize. It's not possible to
address more memory than fits into a usize so having u64 here didn't
really provide much benefit and led to a lot of tedious casting back and
forth all over the place.
BUG=none
TEST=unit tests
Cq-Depend: chromium:2206621
Change-Id: I258f9123c603d9a4c6c5e2d4d10eb4aedf74466d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2203998
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Implement virtio-video decoder which supports hardware-accelerated video
decoding backed by libvda.
Note that this implementation assumes that a guest client uses a fixed-size
set of output buffers. We support a case where arbitrary numbers of buffers
are used by a client like C2V4L2Component in the next CL.
BUG=b:147465619
TEST=Run v4l2-decoder-sample on ARCVM R
TEST=Play YouTube videos on ARCVM R with C2VDAComponent
Change-Id: I3a19381f923ba9c9c0d587dc4ff2c2ee3b31269d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1991380
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This CL adds a fundamental part of the virtio video device, which will
be shared between the encoder and the decoder.
Both devices uses the virtio-video protocol proposed as RFC v3 [1,2].
The corresponding driver code is at CL:2060327 and its children CLs.
The actual decoding and encoding logic will be implemented in different
CLs.
[1]: mail: https://markmail.org/thread/wxdne5re7aaugbjg
[2]: PDF: https://drive.google.com/file/d/1jOsS2WdVhL4PpcWLO8Zukq5J0fXDiWn-/view
BUG=b:147465619, b:140082257
TEST=cargo check --features=video-decoder,video-encoder
TEST=ARCVM started with --video-decoder --video-encoder
Cq-Depend: chromium:2203997
Change-Id: I01999eea218ba0f3aaed1558ca2311a57d0c6819
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1973973
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Update Cargo.lock to match the latest commit.
(Updated automatically via `cargo build`.)
BUG=None
TEST=`cargo build` does not modify Cargo.lock any further
TEST=kokoro passes
Change-Id: I1c022c6111b063eb0d31dda59ed3125c91b49d19
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2209351
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Vms and Vcpus will be try_cloneable and Send, so we can configure on
vcpu threads and so IrqChips can reference all Vcpus. To support
cloning, collection fields in Vm have been moved into arc mutexes, and
Vm and Vcpu are now Sized. Because this breaks object safety, all usage
of the traits will be via static binding.
Add impl AsRawFd for SafeDescriptor, to get the sys_util ioctl functions
working with SafeDescriptor; eventually the functions will change to
take SafeDescriptors. Copy set_user_memory_region helper from kvm
crate.
BUG=chromium:1077058
TEST=cargo test -p hypervisor
Change-Id: I23de47c4472a77632006d0d45de9754394b400c2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2197337
Reviewed-by: Udam Saini <udam@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Steven Richman <srichman@google.com>
With this, Android can access files from host in early stage so
it can import properties from host. To avoid introduce more
command line flags, just reuse the fstab file: any entries begin
with #dt-vendor means a host side file need to be put in device tree.
BUG=b:155128030
TEST=manual - Run ARCVM and check there is file under sysfs
Change-Id: I6b209e05faabd3a82fe0194cf462ee450918ae5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2203298
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Lepton Wu <lepton@chromium.org>
Auto-Submit: Lepton Wu <lepton@chromium.org>
This new module contains the irqchip trait and it's implementations. The
irqchips will work with the new hypervisor crate to abstract the
interaction between crosvm and kvm.
This just defines the irqchip trait and an empty implementation of the
KvmKernelIrqChip.
BUG=chromium:1077058
TEST=added test for creating a KvmKernelIrqChip and adding a Vcpu to it
Change-Id: Ic1609c965e0a057f5a9d4d74f1cae46edb46dcb4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2197398
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
This implementation makes it impossible to use i32 as ordinary data in a
MsgOnSocket implementation. It is also error prone because i32 is the
default type for integer literals in Rust, and #[derive(MsgOnSocket)] on
structs with an i32 would suddenly be transmitting a RawFd.
This change also replaces the uses of RawFd's MsgOnSocket impl for one
based on File.
TEST=cargo build
BUG=None
Change-Id: I9da392e34e62fe61f773f24d656dbcbf4716f1a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2197777
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This caused None values to be transmitted as zero-bytes, which usually
caused not enough buffer space to be allocated for sending.
BUG=None
TEST=cargo test -p msg_socket
Change-Id: If12d2df56689a84054405f2ba15d1c268afad15e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2197776
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
This works around an issue where the xhci controller hangs from the
guest's point of view, with the guest kernel eventually timing out and
disabling the controller.
The xHCI spec says that the EHB (Event Handler Busy) bit should be
cleared before signalling another interrupt. This bit is set by the
controller before triggering an interrupt, and it is meant to be cleared
by the guest (via write-1-to-clear) when it is done handling the
interrupt. However, it seems that there is a race going on between the
clearing and setting of this bit. Removing the check seems to avoid the
issue, since we never get into the state where we think EHB is set but
the guest thinks it is clear (where no further interrupts would be
triggered). This will potentially trigger more interrupts than strictly
necessary, but the Linux kernel xhci driver handles interrupts with no
events available gracefully.
BUG=chromium:1082930
TEST=`while adb shell echo hi; do : ; done` for 8+ hours without hangs
Change-Id: I3c08f0c5675be10d8e46f73714d684f7ba3a3903
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2202745
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The pending variable was just duplicating state that can easily be
determined based on whether the ring is empty. Remove the variable and
replace it with an equivalent check in interrupt_if_needed() to avoid
the possibility of accidentally getting these out of sync.
BUG=chromium:1082930
TEST=cargo test -p devices
Change-Id: Icb90e3d09c43de244f5fecffb0e55d4635be6d2b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2202744
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This adds the ability for getting both supported/emulated cpuids from
the kvm hypervisor. In addition, checking the available capabilities
for kvm is now implemented.
BUG=chromium:1077058
TEST=Added unit tests for each implemented function.
Change-Id: Ide4c2840b7bfa022deae835eb734ea97c1859169
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2177641
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Udam Saini <udam@google.com>
Refactor the DescriptorChainConsumer, Reader, and Writer structs so that
we don't have to allocate a Vec on the heap every time we read or write
from a DescriptorChain. This should hopefully give us some small
performance improvements as well as simplify the code in some places.
Also switch from VolatileSlices to iovecs so that it's easier to use
these structs with io_uring. Otherwise we would end up allocating
temporary vectors to convert from VolatlieSlice to iovec.
BUG=none
TEST=unit tests
Change-Id: I1657bc76cfff084df825dbbdc8ff414740b71a8f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2190106
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Add the AML support to generate the S1 table instead of hard coding.
Also use the IO allocater to allocate the IO resouce for ACPI PM.
BUG=None
TEST=boot crosvm by command "crosvm run -s crosvm.sock -m 4096 --cpus 4
--rwdisk rootfs.img -p "root=/dev/vda rootfstype=ext4" vmlinux".
Check the S1 capability by "#echo standby > /sys/power/state" from guest
side. Linux guest is suspended. And resume linux guest by "#crosvm resume
crosvm.sock" from host side.
Change-Id: I75b484c44db05f98d49557ba694a1531b57871c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2119571
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Add arch-agnostic traits Vm and Vcpu. Add arch-specific traits
HypervisorXXX, VmXXX, VcpuXXX, with impls for KVM.
BUG=chromium:1077058
TEST=added test for functions and structs interacting with the traits
Change-Id: I809f42f32a558c7835831c90e24fca82ce7744ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2176562
Reviewed-by: Udam Saini <udam@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Steven Richman <srichman@google.com>
All 3 different virtio gpu backends share the same process of creating
the GpuDisplay instance, so move that process out of their separate
build functions and put it in the shared BackendKind build function.
BUG=None
TEST=build_test
Change-Id: Ie15bae48c8f1b75df49ba066a677020ec5dbf744
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2182041
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
The trait IntoRawFd isn't marked unsafe, but its documentation says that
an impl must return a uniquely owned RawFd. Some code blocks depended on
that behavior to ensure safety with the unsafe File::from_raw_fd, but
this leads to a soundness hole where a nominally safe impl of IntoRawFd
can lead to unsafety in functions that had been left as safe.
This change sidesteps the issue by not using IntoRawFd, and using only
safe conversions instead.
BUG=None
TEST=cargo build --features='wl-dmabuf plugin'
Change-Id: I9b357e5592be21189fb96e343823dd63000aac30
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2185580
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Auto-Submit: Zach Reizner <zachr@chromium.org>
The AsyncReceiver doesn't need to modify the message receiver so let it
take a plain old borrow.
Change-Id: I07e93d2ed12327dd893fec654d2bdd613a848fe6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2167694
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
An async timer FD will allow block to keep the flush timer when it is
converted to async.
Change-Id: I25759be0f969d1962fd13f33709166527d8f117d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2168644
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
The type of the executor leaked from the cros_async crate. That was fine
until the desire to add a new executor arose. Hide the fd_executor so
that a uring_executor can be substituted on newer kernels.
Change-Id: I8dd309fd47e1b4a6e16da274abbb8431c80474af
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2182042
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Fields with a default value can be skipped using the
`#[msg_on_socket(skip)]` attribute.
TEST=cargo test -p msg_socket
BUG=None
Change-Id: I9fea33e641a7da62b7864ba1847e884b32502491
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2168587
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
These types are simple wrappers, and so this change just adds trivial
passthroughs.
For data sent over a socket, the data is not Arc-ed or Mutex-ed on the
other end with the same ref count or lock. Sending over the data is more
like a deep copy, rather than a simple ref count increase.
TEST=cargo test -p msg_socket
BUG=None
Change-Id: I519096b0b3b6ab75e79c37addf0d60ce3da4a717
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2168586
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
It is useful to have the ability to get a future for only the next
value. This is helpful when borrowing the EventFd for the duration of a
loop is not feasible. It is also helpful for situations where the future
might be dropped. Because dropping a polled eventfd future can leak an
FD, and there is no way to implement a custom `Drop` for the future
returned by stream, using the new `read_next` is the only way to ensure
there aren't any FD leaks if the future might be dropped before
completion.
TEST=added a unit test that makes use of the new feature and mirrors the
existing stream test.
cargo test eventfd_write_read
Change-Id: I9b20c89be561e4a1ca43f2befc66c16188a91d4b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2173973
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Some futures-rs combinators call wake directly instead of using
wake_by_ref. This was left out as on oversight because the initial
executor code only used wake_by_ref.
TEST=run tests with the combinators from futures-rs
Change-Id: I8ac06dfd47d34eee493a5b1194d00ef9d7f6bc18
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2173972
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
