When VFIO device have msix capability, vfio kernel doesn't emulate msix,
so all the msix emulation are handled by crosvm. This include
msix capability register read/write, msix table read/write, msix pba
table read/write.
BUG=chromium:992270
TEST=passthrough a device with msix capabilty to guest, and check device
msix function in guest
Change-Id: Ic39737662a5051ac6b9e29aad227d3d4946190a8
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1987814
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change primarily adds functionality to allow kvm features to be
enabled on a vcpu (most of the current infra only supporst the ioctl for
the vm fd).
BUG=b:144746965
TEST=ran 'build_test' and verified that the added tests passed.
Change-Id: I30c00b6f462377c21d477602ceba5853df953b37
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2055883
Tested-by: Matt Delco <delco@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Matt Delco <delco@chromium.org>
Kvm can emulate the hyper-v paravirt interface. Newer versions of kvm
can advertise the features they support via an ioctl() that reports the
cpuid leafs for this interface. This change adds some support for the
ioctl() and plumbs it through the plugin interface so that plugins can
determine the level of support available in kvm.
BUG=b:144746965
TEST=Ran build_test on kernel that supports the ioctl. Added temporary
code to print the cpuid leafs and verified that the output is as
expected. Instrumented failure as expected from older kernels and
verified that results still passed.
Change-Id: I6cd7dade1793e4edb52b331d5b960685541f7ba3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2037919
Tested-by: Matt Delco <delco@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Matt Delco <delco@chromium.org>
When running plugin tests it's not uncommon to see:
vcpu 0 has internal error
Though the tests don't actually fail on this problem. This seems
to occur as a side effect of the plugin_vcpu_pause.c calling
crosvm_destory_memory() before the test VM has actually finished
running.
The main thread will call read() on the 'kill' eventfd 5 times for:
init, pause, unpause, unpause, kill
The vcpu thread will call write() on the eventfd up to 8 times:
init, pause #1, unpause #1, pause #2, unpause #2, pause #3,
unpause #3, kill
The main thread's third pause request might occur before the second
pause request has been processed, in which case the vcpu thread will
only be paused twice (thus there will only be 6 calls to write()).
Given the unpredictable # of events I've opted to split the
init/pause/unpause events to a separate eventfd and keep the 'kill'
eventfd solely for its intended purpose.
BUG=None
TEST=ran ./build_test several times and observed no failures in the
pause plugin test.
Change-Id: Ie0817a4419ae6199fcc5c53496360b2bd81556e3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2012788
Reviewed-by: Matt Delco <delco@chromium.org>
Commit-Queue: Matt Delco <delco@chromium.org>
Tested-by: Matt Delco <delco@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This change unifies two substantially similiar segments of code used to
create a jail.
BUG=none
TEST=Ran 'build_test'. Local build, deployed to DUT, and verified that
termina VM could still be used.
Change-Id: Ib1f2f9bc5cfe1e6c9f3633af7e23f52e5eafe3c7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2057744
Tested-by: Matt Delco <delco@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Matt Delco <delco@chromium.org>
When msix is enabled, msix will have multi vectors, this patch enable
mutlti vectors in vfio_device.irq_enable() function.
BUG=chromium:992270
TEST=passthrough a device with msix capability to guest, and check
device msix function in guest
Change-Id: I5f8265e7badec8551ff9a974462f08425ee93ab2
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1987813
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The flag in avail descriptor supplies irq suppress, it could reduce irq
injection from device, so many redundant interrupts could be removed
from guest, then improve guest performance.
BUG=None
TEST=run fio read and fio write in guest
Change-Id: I68789d8ca24d0e84d0b446db65057f4da2fac56f
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2008339
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
For suspend request from VM, will write suspend event and notify
crosvm main process to pause VCPUs.
For resume request, it is not from VM itself but by the resume
command through crosvm socket. Resume request will notify the PM
device to fill its wakeup registers with wakeup event so that
when VCPUs start to run, VM can know there is wakeup from outside.
BUG=chromium:1018674
TEST=cargo test -p devices
Change-Id: I4724ffee10150065a62bf520076c16cbc70b7749
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035169
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Adds a method Reader::collect() to read a collection of DataInit types,
and a method Writer::consume() to write a collection of DataInit types.
BUG=b:147334004
TEST=cargo test -p devices
Change-Id: Ib5947d30b44b74dc6cf0474e5b87778aad6f08a0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2061516
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Adds a new backend type, gfxstream, that calls out to a C library
implementing the actual rendering.
The purpose is to allow the Cuttlefish and Android Studio Emulator teams
to use crosvm with the current API-forwarding style of rendering
employed in the Android Studio Emulator.
Also, introduces a new key to the --gpu command line interface,
backend=, which selects from different backends. Note that the previous
behavior is now deprecated and will be removed after some time
(when all clients switch over to backend=).
The gfxstream backend itself implements a subset of 3d-related resource
and context creation/transfer/execbuffer commands. Their meaning is
specific to the way in which they are interpreted in the backend
library.
To interface with display, gfx stream backend takes a callback that is
run on guest vsync. The callback is responsible for repainting the
display's contents. gfx stream provides a callback, get_pixels, that can
be used asynchronously. The asyncness is not taken advantage of
currently but will be useful for cases where the client attached to the
VMM might want to update at a different rate than guest vsync.
The guts of the stream backend library is currently defined here:
https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-master-dev/android-qemu2-glue/emulation/virtio-goldfish-pipe.cpp
The linking of the library is controlled via the feature "gfxstream".
If the feature is turned off, we use a default do-nothing stub impl.
Next steps:
- integrate virtio-gpu-next so as to have host coherent memory for
vulkan
- Figure out low latency command submit/response with SUBMIT_CMD_3DV2
BUG=b:146066070
Change-Id: If647381c15e5459cec85e2325f97e2f0a963b083
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2033305
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Auto-Submit: Lingfeng Yang <lfy@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Current blk interrupt is injected into guest after device handle a
batch of requests. While this patch injects interrupt at the end of each
request. So guest block will get much more interrupts and could handle
request more quickly.
With this patch, the guest fio read test improves 13%, while fio write
doesn't get better.
BUG=none
TEST=run fio_read and fio_write in guest
Change-Id: Ib0bd23e624dfc5d940d6cc124468b898d8ba128e
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2008338
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Move the minijail source checkout location in the Dockerfile so that it
is in the expected place relative to the crosvm checkout so that Docker
(and kokoro) can successfully find it.
Also update Cargo.lock for the new minijail-sys dependency; this fixes
"read-only filesystem" errors from cargo running inside Docker when it
tries to write the updated Cargo.lock.
BUG=None
TEST=docker/build_crosvm_base.sh && docker/wrapped_smoke_test.sh
Change-Id: Ic399030004c2c4891a03a60474348b0bed9f01d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2062675
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Drop the local DiskFile trait definition from qcow_utils and use the one
defined by the disk crate, since qcow_utils already depends on disk.
In order to make the switch, use the DiskGetLen::get_len function
instead of seeking to the end of the file to get the current file size.
BUG=None
TEST=emerge-nami crosvm
TEST=cargo build -p qcow_utils
Change-Id: Ie4b3b8ee0fb11ef02fbc322c5b0f9e22b0345bb0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2056991
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add ACPI PM resource emulation code in devices, so that it can support
the ACPI PM requestion from guest OS.
BUG=chromium:1018674
TEST=cargo test -p devices
Change-Id: I7b82b1c3a6f609136e493b55420b947afd1d5cfc
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035168
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Having this property in the chosen node in conjuction with
CONFIG_RANDOM_TRUST_BOOTLOADER lets us seed the kernel's random number
generator with some truly random numbers. This is useful to get a better
stack canary than the default build time one and it means that you
should see a message like:
random: get_random_bytes called from start_kernel+0x1e8/0x39c with crng_init=1
instead of a message like
random: get_random_bytes called from start_kernel+0x1e8/0x39c with crng_init=0
in the kernel logs. We seed 256 bytes here because that seems good
enough to kick start the rng.
BUG=None
TEST=Boot vm, see crng_init=1 when guest kernel has
CONFIG_RANDOM_TRUST_BOOTLOADER=y
Change-Id: If3689f56cc17204a16410cf368e8413de160646c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2055526
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Stephen Boyd <swboyd@chromium.org>
Commit-Queue: Stephen Boyd <swboyd@chromium.org>
Stop using 30 and 31 as device IDs of virtio-wl and
virtio-tpm, as these numbers were reserved for virtio-video devices
in the upstream [1].
Instead, use integers from 63, which is the largest
number we can use for a virtio device ID.
Note that this CL must be merged after kernels with CL:2024135 landed.
[1]: https://github.com/oasis-tcs/virtio-spec/issues/67
BUG=chromium:1031512
TEST=Check if /dev/wl0 exists on ARCVM with CL:2024135
Change-Id: I267c7702d3c28642492f560170a0d1d9d6523c31
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2025127
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Commit-Queue: Fergus Dall <sidereal@google.com>
Copy the IRC text from the chromium docs, giving users a place to go ask
questions.
Change-Id: I9466cb3058823b6afd65ff2912b05d8a70d70229
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2052390
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Dylan Reid <dgreid@chromium.org>
When the user specifies the display size through the gpu argument but
not specifies the size of the single touch device, the display size
will be used as the size of these touch devices.
Use default() to initialize the GpuParameters. Allow initialize the
GpuParameters dynamically in the future.
Change-Id: I9fa04f8ff479732370514fbaeb062d737adba319
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2043072
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Loop vfio device config register, then find out the msi and msix
pci capability.
both msi and msix need IrqRequestSocket for adding its routing info
into kvm routing table, but vfio device has one IrqRequestSocket only,
and only msi or msix is enabled at runtime, so Arc is used to let msi
and msix share one device IrqRequestSocket.
BUG=chromium:992270
TEST=pass a device with msix capability to guest, and check device msix
function in guest
Change-Id: I008ccd0e98507dc4d587418fbe00aa23029bdbad
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1987812
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Uprev the pinned commit and update Cargo.lock to match:
- libcras no longer depends directly on sync
- cras-sys now depends on audio_streams
- audio_streams now depends on sync and sys_util
BUG=None
TEST=`cargo build` and verify Cargo.lock is unchanged
TEST=docker/build_crosm_base.sh && docker/wrapped_smoke_test.sh
Change-Id: Iba1fba57284e1e233725e4086d5d98bb460f118c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2047492
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
This is no longer used after the bindings were updated to use c_ulong
instead of c_long; remove it to fix a compiler warning.
BUG=None
TEST=cargo build
Change-Id: I813b06797ddc8b6cdfd8b777bd0a6efe6ec914a4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2047643
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
We're currently adding 'kaslr' to the chosen node, with a value of 0.
I'm not sure what that does, but we should probably add an actual random
value here. There is a 'kaslr-seed' property that can be written into
chosen and used to randomize the kernel address in memory. Let's
populate that property instead so we get some sort of random kernel
location in memory.
BUG=None
TEST=Boot up guest on cheza, hexdump kaslr-seed in
/sys/firmware/devicetree and see that it's been changed to 0
Change-Id: I3f7b1ac64174bcf2e9010df992c2b2553ff90979
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2040476
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Stephen Boyd <swboyd@chromium.org>
Commit-Queue: Stephen Boyd <swboyd@chromium.org>
This crate will provide asynchronous helpers wrapping primitives
provided by sys_util. To start EventFDs and MsgReceivers are provided.
Change-Id: Ia8862adafca995a3e3ab56582acc166a37fc8d2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1955046
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
This crate will house code using the new async/await features to be used
by other parts of crosvm.
Start the crate with a Future executor that runs tasks in a single
thread and allows futures that block on system file descriptors.
Change-Id: If77778ac056210dabbfc6e6e1e63df1c1b904a7f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1955045
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Driver use virtio_wmb() before avail_index updating, here fence() is
compared with it, this guarantee that the descriptor_index is read after
avail_index.
BUG=none
TEST=run fio_read and fio_write in guest
Change-Id: I6a5e1bc7c915effd433b05aca246302c5a3e313c
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035079
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
The EventFd that wraps the MaybeOwnedFd will close the fd, but so will
MaybeOwnedFd, causing a double-close.
BUG=None
TEST=strace crosvm run
Change-Id: I277386cd20eaa1a8187274cc16084b1936355012
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034026
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change adds the `recv_*_vec` suite of methods for getting an entire
packet into a `Vec` without needing to know the packet size through some
other means.
TEST=cargo test -p sys_util -p msg_socket
BUG=None
Change-Id: Ia4f931ccb91f6de6ee2103387fd95dfad3d3d38b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034025
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The build-time seccomp compiler for aarch64 complains that it doesn't
recognize open, epoll_wait, recv, mmap2, dup2, poll, mkdir, or stat.
I tried to propose a change to upstream minijail to make it aware of
these syscalls, but the calls are in various forms of deprecation
so upstream is doubting the sanity of the policy files.
I applied the following mapping: open->openat, epoll_wait->epoll_pwait,
recv->recvfrom, mmap2->mmap, dup2->dup3, poll->ppoll, mkdir->mkdirat,
and stat->statx. In many cases the new syscall was already present so I
just deleted the old one.
BUG=None
TEST=Ran compile_seccomp_policy.py with an unmodified minijail until
it stopped complaining. I don't have an arm device for runtime testing.
Wrote an app to emulate the execution of the first 400 syscall #s though
the bpf filter and verified that the list that matches the filter is the
same as the policy file.
Change-Id: I599aa549a1712b898eb6b73492872a9676e7215d
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2036218
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Vhost-net reset method can stop the activate thread and let it to
return the ownership of eventfds and tap back to the device, so that
it is possible to be activated again.
BUG=None
TEST=launch Crosvm guest with vhost-net. It works fine with iperf test.
TEST=cargo test -p devices
Change-Id: I8f3cb6939595b4dffa0e95bcffbf9fcc8fcf71ba
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2009665
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
the event_source needs to be returned through the reset method to allow
the virtio-input device model reactivated again.
BUG=None
TEST=cargo test -p devices
Change-Id: I07a4add40b1c233e1ed328ccef1a1abd453ea0f7
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2032351
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
These were pinned at pre-1.0 versions. Update to the stable API to allow
new features to be used in the future.
Cq-Depend: chromium:2026764
Change-Id: Id2d979525e5210436cbb1cfa61e2b05fafb288f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2025907
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
worker.run might encounter error when running but we still need it
to give the ownerships of the kill eventfd back so that it
can have a second round activate. And Worker structure also contains
several other eventfds which will be needed for a second round activate
so change to put this eventfd into Worker as well.
BUG=None
TEST=launch Crosvm guest with vhost-net and vsock. Both of them work fine.
TEST=cargo test -p devices
Change-Id: I34477cfa3de23d7ab849f741d0ffb098c720a629
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2009664
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
The high 32 bits of writable_bits was set incorrectly when adding 64-bit
memory BARs to PciConfiguration: it would effectively always be all
zeroes (no writable bits) instead of all ones (all writable bits).
The writable_bits field is used to determine which bits to force to 0
when reading the BAR, which is used by the guest to determine the size
of a BAR: write an all-ones value to the BAR, read it back, and the
resulting value has only the writable bits still set. Since PCI BARs
must be a power of two in size, the effective size of the BAR is the
bitwise inverse of the resulting value plus one.
For 64-bit BARs, this process is the same, except that two contiguous
32-bit registers are combined, so for a 4096-byte 64-bit BAR, the
writable_bits field should be 0xFFFFFFFF_FFFFF000; however, with the
previous (buggy) code, it was 0x00000000_FFFFF000.
Add checks to the unit tests to verify that the writable_bits field is
correctly calculated as well.
BUG=None
TEST=cargo test -p devices pci_configuration
TEST=Boot Linux 4.19 kernel in crosvm
Change-Id: Ib97aa5dccf9bf042328c0fc9defe1797fc67bb05
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2033620
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The default is 2015 and that causes any usage of `async` to cause kokoro
errors.
Change-Id: I9f962b6f578b0d1992377dfefdd724c080a6f1b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2024365
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Minijail's policy compiler complains when there's multiple
unconditional rules for a syscall. In most cases the rules
are redundant to common_device.policy.
BUG=None
TEST=Ran compile_seccomp_policy.py until it stopped
complaining.
Change-Id: Ic43d1fd13f9c012641d71e526942229eb8b08ed4
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034024
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Allow mounts from the parent namespace to propagate into the mount
namespace of the 9p device process.
BUG=none
TEST=none
Change-Id: Iff455c8967949bd3e0f2990c947d45bbbc541d45
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2018305
Reviewed-by: Yusuke Sato <yusukes@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Yusuke Sato <yusukes@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Transfer TRBs have a flag that indicates that data is transferred within
the TRB itself instead of as a separate buffer. Add support for this
type of transfer in the ScatterGatherBuffer implementation.
This fixes USB support when using Linux 5.1+ as the guest kernel, since
it now uses immediate data transfers.
BUG=chromium:1046564
TEST=`adb root` to connected phone on Linux 5.4 guest kernel
Change-Id: I6c37db422ac8e65d10e1a91807b15e903ad614de
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2026262
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add a function to get a resource FD via resource_bridge by extracting code from
the wayland device implementation.
This function will be used by virtio-video devices.
BUG=b:147465619
TEST=Run ARCVM and check that a window is displayed
Change-Id: I7b064c9a04bd082e30dd488d0b14731228e6047d
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2014520
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
... which does not require virglrenderer (or any renderer).
This will allow the Cuttlefish team to use minigbm as its gralloc
implementation when both hardware acceleration is available and
unavailable.
Adds a GPU `Backend` trait with all of the existing methods of the
current backend and converts the existing `Backend` into
`Virtio3DBackend` which implements the new trait.
Adds a `Virtio2DBackend` which creates resources with byte vectors on
the host and implements transfers via the old code from
gpu_buffer/src/lib.rs.
Adds a runtime flag to select between 2D and 3D mode with 3D mode as
the default.
Moves the process_resource_bridge() function to the `Frontend` and
instead expose a export_resource() function on the `Backend` to avoid
some code duplication.
BUG=b:123764798
TEST=build + launch cuttlefish w/ 2D mode (minigbm + custom hwcomposer)
TEST=built + launch cuttlefish w/ 2D mode (minigbm + drm_hwcomposer)
TEST=built + launch cuttlefish w/ 3D mode (minigbm + drm_hwcomposer)
Change-Id: Ie5b7a6f80f7e0da72a910644ba42d2f34b246be8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1993913
Commit-Queue: Jason Macnak <natsu@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Set the backend with null fd can reset the vq in vhost, which
can allow the activate fn to run again.
BUG=None
TEST=launch Crosvm guest with vhost-net. It works fine with iperf test.
TEST=cargo test -p devices
Change-Id: Ida952409147fd6fbd1d8f69b3a88a7ef03051d65
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2009523
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Adds support for pstore on ARCVM on x86_64.
The backend file of the buffer will be passed via argument of the crosvm.
BUG=b:144962428
TEST=kernel crash on eve-arcvm, check /sys/fs/pstore/console-ramoops-0
Launch crostini manually on eve-arcvm
Change-Id: I29492ac7a9067aa2ae23eb03fbb942ab7dd3aa8d
Signed-off-by: Kansho Nishida <kansho@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1973391
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kansho Nishida <kansho@chromium.org>
The VCPU thread can panic when there is a bug, and this should trigger
an exit in crosvm instead of hanging the VCPU thread forever.
BUG=None
TEST=run crosvm with kernel, trigger a vcpu exit using guest
Change-Id: I1df0e04eda73ad67fec20adeff893f6c00699318
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2029929
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
The original version of this test used sleeps, retries, and vague
commentary about how the test is made reliable. The new version of test
uses real synchronization primitives..
BUG=chromium:1045426
TEST=put all cores under load;
cargo test -p data_model
Change-Id: I7fa4ac45a9003e2ebb98c57ca6a03be17bdf65cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2029925
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
The plan is to use shared mem cap for virtio-gpu.
BUG=chromium:924405
TEST=build
Change-Id: Id2829c2cd9883aca19641eff625c65a8db335e7a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1963334
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>
When a non-sparse disk is resized, we should allocate storage for the
newly-expanded space when the disk is grown to maintain the
non-sparseness. To accomplish this, add a call to allocate in the
resize function in the block device.
BUG=chromium:858815
TEST=`crosvm disk resize ...` and verify disk image is fully allocated
Change-Id: If263aa2b5c9da11b8bfc0586e4ac1575f2bd7084
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2015829
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This trait provides a generic interface for allocating space on the
filesystem within a given file. It is equivalent to the fallocate(2)
system call with the default mode (mode = 0).
BUG=chromium:858815
TEST=cargo build --features=composite-disk
Change-Id: I2f4e8aceb4878790e8dec2e3d539071915efd205
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2015828
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
