Add support for guest fences backed by host sync_files. Rather than
adding a new fence type, fences are implemented as vfds that only
support hup. The host simply waits on the sync_file and sends the guest
a hup when the fence is signaled.
BUG=b:169908659
TEST=Revert ag/15543199, resize ArcCameraFpsTest
Change-Id: I8c79ec9f418b1d71150b5a19f500c5ac7a6c9b02
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3199298
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When device memory/io is disabled, its mmio/io range should be
removed from mmio_bus/io_bus.
When device memory/io is enabled, its mmio/io range should be
added into mmio_bus/io_bus.
BUG=b:174705596
TEST=Boot a vm, monitor device mmio/io enable/disable, then check
vm function.
Change-Id: Ic77565b9828599d574329bea76146cff597a94fe
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3252778
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When device's bar are reallocated, all the old resource ranges should be
deleted, the new resouce ranges shoud be added, this commit add the
interface to get device mmmio/io old/new ranges.
BUG=b:174705596
TEST=Boot a vm, monitor device bar reallocation and check function
Change-Id: I1000607d9f766ff8b445bf92f17969b094f3b2ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2718280
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
When device's bar is reallocated, the old ranges will be deleted,
this commit add remove() function to delete one old range from
bus->devices.
BUG=b:174705596
TEST=Boot a vm, monitor Bar Reallocation then check function
Change-Id: Id0600ae1d7a3d04c7f05a90abcc8807b7f1020c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184725
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change contains the results of running
./tools/contib/cargo_refactor.py
This will break the next uprev, and needs to be synchronizized
with the corresponding ebuild changes in https://crrev.com/c/3248925
BUG=b:195126527
TEST=./tools/run_tests
Change-Id: Ied15a1841887bb8f59fba65b912b81acf69beb73
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3248129
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Introduce a very simple stub PCI device that can be added to the bus
at a specified address with given PCI config parameters (vendor,
device, etc.). This is useful for cases where we just require a device
to be present during PCI enumeration.
The case that motivates this is a vfio device passthrough
configuration that passes only selected functions of a given device at
the original addresses, but function 0 is not passed through. Absence
of function 0 would be interpreted in enumeration as the entire device
being absent (in accordance with the specification). Putting a stub
device at function 0 fixes this.
BUG=b:167947780
TEST=New unit test, boot minimal Linux image and verify enumerated PCI device.
Change-Id: Iaedffe1c4ac2ad8f6ff6e00dfeebbbfeb5490551
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3245497
Auto-Submit: Mattias Nissler <mnissler@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This is useful for example when parsing numeric PCI class code values
from the command line.
BUG=b:167947780
TEST=None
Change-Id: I55515af2fa7e38bc26f4c2eebb083f1e45aebf22
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3245496
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
It's the highest bit in the header type field, this change allows to
set the bit and thus indicate that a device is a multifunction device.
BUG=b:167947780
TEST=None
Change-Id: I71372e2490897bc3d5c24717c9504e337792a48f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3245495
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Like disks, serial devices can be backed by file descriptors using the
/proc/self/fd/N syntax.
BUG=b:200914564
TEST:cargo test
Change-Id: Idd6f5763db24e61a80dc34732c9e2118d613cefc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3241083
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Rust bindgen now supports --allowlist and --blocklist option names as of
https://github.com/rust-lang/rust-bindgen/pull/1990 - use them in the
various bindgen invocations in scripts and comments.
BUG=b:178821708
TEST=../dev/contrib/search_blocked_words.sh unblocked_terms.txt
Change-Id: I9797f049999a01ab2c41617823463236b4d03cbb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3243012
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
According to pci bridge spec, the io/mem/prefetch mem limit register
must be programmed to a smaller value than the corresponding base register
if there is no io/mem/prefetch mem on the secondary side of the brige.
When bridge is created, it doesn't have any child device, then
no io/mem/prefetch mem on the secondary side of the bridge, so this
patch set limit to 0, but base to 0xffff.
When a device is attached behind the bridge, kernel will assign
resource and set the right value to these base and limit register.
BUG=b:199442120
BUG=b:185084350
TEST=crosvm run --bios OVMF.fd
TEST=hotplug in/out a pcie device to pcie root port repeatly
Change-Id: Id1c2ff1132d59e1aafd548fc17ab5aee2023dd8c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3166883
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
With vfio pci device hotplug, bus->devices will be inserted and removed at
runtime in different vcpu threads, so mutex should be used to protect it.
Both each vcpu thread and pci_root share mmio_bus and io_bus, so use Arc
for mmio_bus and io_bus. But pci_root is inserted into io_bus for pci cfg io,
in order to resolve reference loop and memory leak, weak is used for
pci_root.mmio_bus and pci_root.io_bus.
BUG=b:174705596
TEST=boot a vm and check its function
Change-Id: I7b3e63db76a90bc3873619b4d80a66db741ce78f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184724
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The strategy of passing Vec<u8> types introduced in crrev.com/c/2470376
can cause panics when the receiving side doesn't have the capacity to
receive the full buffers produced by crosvm. For example, a
virtio-console implementation with only one-byte buffers
(https://android-review.googlesource.com/c/1853082) almost always won't
have the capacity to receive the full buffers.
Using a VecDeque ring buffer allows continually appending data from the
input in the read thread and pulling off as much as the guest can handle
in the guest communication thread, without sacrificing performance when
the guest can handle higher volumes.
Bug: b/182849835
Bug: b/203138623
Test: Pass some input with an unbuffered single-character console driver
Test: Run CtsKeystoreTestCases against cuttlefish (high volume transfers)
Change-Id: I6b52a729d5af82f4626a9b1f29176116299b9297
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3227733
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Move the definition of VfioPciConfig, which is currently used by VFIO
passthrough, to vfio.rs so that we can use them when implementing VFIO
driver.
BUG=b:194137301
TEST=cargo build
Change-Id: Ia35d04d1871f5d4917dba81c1b4cc49bfbc3bf4b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3149870
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Add Doorbell type in VhostUserBackend trait.
While it's CallEvent type having an underlying callfd for vhost-user, it'll be a doorbell struct for virtio-vhost-user.
BUG=b:194137301
TEST=cargo test
Change-Id: I569870b8285c6e82423e0d478f83dce7e08d386b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3205229
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Includes some fixes for new clippy checks. A rebuilt
dev_container that ships the new toolchain.
This allows us to get rid of the annoying cargo clean
before running clippy.
BUG=b:203142205
TEST=./tools/presubmit
Change-Id: I9d486fbcf7b2d468f6a1375ac7df95091a2c1465
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3232277
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
in preparation for vhost-user device implementation.
* Use <I: SignalableInterrupt> in handle_*_queue methods. start_queue of
VhostUserBackend has a different interrupt type.
* Avoid sharing of pcm queues to ctrl queue. start_queue of
VhostUserBackend is called per queue, and provides the queue object
for that queue only.
BUG=b:179755683
TEST=tast run $DUT_IP vm.Audio*.virtio_cras_snd
Change-Id: Ic53135ac317896f1ebeb3b11795e80736c466996
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3168560
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Use the crates.io implementation of tempfile instead of our own version.
Our reimplementation is kept in the tree for now in case of dependencies
outside of the crosvm tree; it can be removed later once those are fully
switched over to the crates.io implementation.
BUG=b:199204746
TEST=emerge-hatch crosvm
Change-Id: I07d3404239302ab9a17f4ddc82a9479b256e4eb4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3209839
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
If the guest sends a VIRTIO_BLK_T_GET_ID request and the block device
does not have an ID configured, crosvm prints an error message:
[devices/src/virtio/block/asynchronous.rs:191] failed executing disk
request: unsupported (8)
Since there is no corresponding feature flag for GET_ID support, the
guest can only detect if the command is supported by just trying it.
However, the error message is confusing to the crosvm user, since this
request failure is not indicative of a problem, just a part of normal
operation.
To avoid this confusion, suppress the error message when GET_ID fails
while still returning the unsupported status to the guest.
BUG=None
TEST=crosvm run -r vm_rootfs.img vm_kernel # check syslog for no error
Change-Id: I05fcd3c428ff1314998ac88fd92d78423155dba3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3213115
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add the vmm side for the vhost-user vsock device.
BUG=b:179756331
TEST=Connect to vshd inside a VM with a vhost-user vsock device
Change-Id: I332adbb6f8d6cfc8dff16375e93d946ecad2e84b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3153213
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Since vhost-user messages have a 1:1 mapping to vhost ioctls, this
device doesn't use DeviceRequestHandler but processes incoming messages
directly.
BUG=b:179756331
TEST=Connect to vshd inside a VM with a vhost-user vsock device
Cq-Depend: chromium:3105429
Change-Id: I9811e29282f7e79140be1203bce9030ec37a3343
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3153212
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Platform device is another type of device which might be assigned
directly to VM by using the same IOMMU DMA isolation technique.
In contrary to PCI, platform device has no config space which
describes device resources and makes it self-contained and
self-discoverable. Therefore, platform device resources are described in
FW and host is the one who enumerates/probes devices by parsing DT/ACPI.
We have ioctl i/f which allows to expose all that info to VMM.
Add platform bus specific calls to interact with host properly and
plug in to aarch64 bus creation code.
Note, for now all IRQs are abstracted to wired line (SPI in ARM GIC world)
which means guest wont see MSI-X for platform devices.
BUG=b:185504618
TEST=trogdor64-manatee SDHCI and GENIQUP device passthrough boots/works
Change-Id: Id0e9efde3586af77ed1d0b8bf79ca485906afb83
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2961216
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Commit-Queue: Micah Morton <mortonm@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Some devices (like platform device) has no PCI config which describes
associated IRQs. Instead, IRQs are described either via DT or ACPI.
In any case, host is the one who keeps that info and needs to expose
to VMM. Add function to collect IRQs info for further processing.
BUG=b:185504618
TEST=trogdor64-manatee SDHCI and GENIQUP device passthrough boots/works
Change-Id: Ica7d60d50b905968285f61722897ef150d419a56
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2961215
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
In preparation for adding VFIO platform support add function which
allows to get number of regions and size of specific region.
BUG=b:185504618
TEST=trogdor64-manatee SDHCI and GENIQUP device passthrough boots/works
Change-Id: I4ad99d7658d5b76cae4aa686b2b1f772e2bc3e44
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2961214
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Micah Morton <mortonm@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Google drive and file systems used for external media (like FAT32) don't
support xattrs, which means they also don't support posix acls.
However, we unconditionally enable FUSE support for posix acls
preventing us from using virtio-fs for those mount points.
Make posix acl support optional so that we can also use virtio-fs for
gdrive and external media. This feature is on-by-default since we
currently use it for every other virtio-fs mount point.
BUG=b:196946147
TEST=arc.PlayStore.vm
Change-Id: I9139852d6dceb46bef21af43f77fc527f3fa58d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3168564
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This change adds the bar index and offset to the read_bar and write_bar
methods to the VirtioDevice trait. VirtioDevice needs these parameters
to implement the device bars.
BUG=b:194136484
TEST=Compile.
Change-Id: I48cb6e743b29467dc9707e13ce72b6b61951a6db
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3188668
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Auto-Submit: Abhishek Bhardwaj <abhishekbh@chromium.org>
This reverts commit 79d6696394.
Reason for revert: The change made it through to ChromeOS builds
because the audio_streams ebuild is not manually upreved yet. Re-submit after https://crrev.com/c/3192217 is landed.
Original change's description:
> Add StreamEffect to new(_async)_capture_stream
>
> It is needed to support AEC in virtio-snd (cras backend)
>
> BUG=b:201472965
> TEST=cargo test
>
> Change-Id: If79eee8a41d1da7e6d643e8187bbc75768f31ad9
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3193841
> Reviewed-by: Judy Hsiao <judyhsiao@google.com>
> Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
> Commit-Queue: Dennis Kempin <denniskempin@google.com>
> Tested-by: kokoro <noreply+kokoro@google.com>
Bug: b:201472965
Change-Id: Ib68978ea148ae3598109a779e620377f7f1f9d94
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3200179
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
It is needed to support AEC in virtio-snd (cras backend)
BUG=b:201472965
TEST=cargo test
Change-Id: If79eee8a41d1da7e6d643e8187bbc75768f31ad9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3193841
Reviewed-by: Judy Hsiao <judyhsiao@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
We don't currently have it enabled anywhere but we still always allocate
PCI shared memory regions for it. Instead make it optional and off by
default. We can re-enable it on a per-device basis.
BUG=none
TEST=arc.PlayStore.vm
Change-Id: Icf122a561251a3e55757a9ffe4633b96adc4066d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3168563
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Acquire/Release orderings are not sufficient when accessing memory
that's also touched by the guest kernel. Use SeqCst ordering, which
also more closely matches what the kernel does.
BUG=b:200637442
TEST=Run vm.Virtiofs 15 times in a row both with and without
VIRTIO_RING_F_EVENT_IDX enabled and observe that the test does not
hang
Change-Id: I54f1d7123bdcbbf01f94935193e48a9c2e252bbc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3199301
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Before we call build_vm we are creating devices and there is no reason
to assume those have to be PCI only. In preparation for VFIO platform
device support, add super trait which allows to pass generic device
structure around and still be able get back to our original type.
BUG=b:185504618
TEST=manatee PCI device passthrough boots/works
Change-Id: I500f44af430f5f06299f20fc4ca17ca008a7e0c5
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2961210
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
If we need descriptor for things that aren't file or other shared_memory objects, we can create a separate descriptor change, but it shouldn't be the default.
This reverts commit 533c5c8258.
Reason for revert: this causes conflicts with other platforms.
Original change's description:
> vm_memory: Add from_desciptor() in MemoryMappingBuilder
>
> MemoryMappingBuilder had `from_file()` and `from_shared_memory`, which
> are almost the same. So, this commit adds `from_descriptor()` to replace
> both of the two.
>
> BUG=b:194137301
> TEST=build
>
> Change-Id: Ia13f5e8e0f95a5c32e47dc9b3be13b7a7fa510bf
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3159881
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
> Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Bug: b:194137301
Change-Id: Ie203ee3eb3dcddd41c5e55b6980dc6292eb24f85
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3183183
Auto-Submit: Udam Saini <udam@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Udam Saini <udam@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This change plumbs read_bar and write_bar methods to the VirtioDevice
trait. VirtioDevice exposes PCI bars and the virtio vhost user proxy
device would need these methods.
BUG=b:194136484
TEST=Compile.
Change-Id: Ib65d0fb81feb8af6913a2c2c2bdba80ef6d20d31
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3176396
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Auto-Submit: Abhishek Bhardwaj <abhishekbh@chromium.org>
When outputting a picture there is a bit of code that updates the size
of each output plane to the size of the visible rect. This looks wrong
on several accounts:
1) The plane size should already have been computed when we received the
buffers,
2) With this code each plane is assigned the same size, which is
obviously wrong with formats such as NV12,
3) The size in bytes of a plane depends on the coded size, not the
visible size.
Looking at the git history it appears that this code has been here since
the initial revision of the decoder, and then moved around. Maybe it was
just here to make things work in the beginning and slipped under the
radar. In any case, removing that code does not seem to hurt.
BUG=b:161774071
BUG=b:169295147
TEST=Android Youtube plays properly on Hatch.
Change-Id: I6c8949c49c070daaa3540b757dd35469b571c43c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026344
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
It's a little bit less wordy.
BUG=b:150239451
TEST=none
Change-Id: Ia25ac6b3db77ce8e9b074273967294909fb56e87
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3173067
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
VFIO-PCI device has its own region naming but eventually it starts from 0
(as well as it suppose for others VFIO device types) so simply use 0
instead of VFIO_PCI_BAR0_REGION_INDEX.
At the same time move PCI-specific checks to helper function for clarity.
BUG=b:185504618
TEST=manatee PCI device passthrough boots/works
Change-Id: I404a9585016d230c48a6db7248172d2381a0a3e1
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2961213
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
MemoryMappingBuilder had `from_file()` and `from_shared_memory`, which
are almost the same. So, this commit adds `from_descriptor()` to replace
both of the two.
BUG=b:194137301
TEST=build
Change-Id: Ia13f5e8e0f95a5c32e47dc9b3be13b7a7fa510bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3159881
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Complete vhost worker queue init before spawning thread routine.
Enabling a virtio devices requires updating the
VIRTIO_CONFIG_S_DRIVER_OK bit, which signifies that the devices is
ready to process the virtio queue. Do this before spawning the worker
thread in order to avoid the situation where a guest VM starts using the
queues before initialization has been completed.
Also make this fix for vhost net and vsock.
BUG=b:200658613
TEST=boot with vhost-net interface and check that network is working fine
Change-Id: Ibc505ba63d692d9c5380d9ec3b6f80d75ff99181
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3015206
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Nowicki <tnowicki@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change adds the PCI device that will act as the conduit between
vhost vmm and vhost device in a virtio-vhost-user
specification. It only implements the communication logic i.e. rx / tx
from the vmm socket and virtio queues associated with the device.
BUG=b:194136484
TEST=Compile.
Change-Id: Ib47045b7633b77b73ed7bd428ca981caa6645275
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3146213
Auto-Submit: Abhishek Bhardwaj <abhishekbh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
GuestMemory is only needed for the set_mem_table and set_vring_addr
methods so take it in as a parameter there rather than storing it in the
struct. Vhost-user devices don't have access to GuestMemory when the
vhost device is first constructed.
BUG=b:179756331
TEST=unit tests
Change-Id: Id446db43777c26b0dfbe8b37366f2da93de53b23
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3153211
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This CL adds a vhost user FS device to crosvm. The implementation
requires the following arguments:
--socket = a path to a unix socket crosvm is going to connect to
--tag = a virtio fs tag to mount within the VM
--shared-dir = path to the shared directory
Optional arguments are:
--uid-map = UID translation from inside the VM to the outside
--gid-map = GID translation from inside the VM to the outside
Example command:
crosvm device fs --socket $HOME/test --tag fs-tag --shared-dir $DIR
crosvm run --vhost-user-fs=$HOME/test:fs-tag ...
BUG=b:179636297
TEST=launch fs device and verified that mounted directory works
Change-Id: Icab9e4be65092ef817006408b50bb3bf35033c62
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3062161
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Morg <morg@chromium.org>
Commit-Queue: Morg <morg@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Update to the latest version of vmm_vhost to pick up the API change.
Also fix clippy errors in the gpu device.
BUG=b:179755651
TEST=cargo build
Change-Id: Ia42681aee1d92f38dfcca1fbf87e8cfd7ac15d95
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3151109
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
A NV12 frame is made of one Y plane at full resolution, and one plane
include one U and one V component for each four pixels. Thus the size of
the second plane should be half of that of the first one.
This is important to get right as ffmpeg conversion functions wil rely
on this information and will fail if the computed size is bigger than
the target buffer.
BUG=b:161774071
BUG=b:169295147
TEST=Android Youtube plays properly on Hatch.
Change-Id: I4196983389def3a4914c076d68067874041fab55
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3023743
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The fsverity_enable_arg struct contains optional pointers to additional
data. Check for them and try to copy them in if necessary. This
requires a corresponding kernel change where the fuse driver also
reads the struct and copies the relevant data from the userspace
application.
Steps to test this change:
// Create a test file
head -c 1000000 /dev/urandom > file
// Generate a new certificate and private key:
openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -out cert.pem
// Convert the certificate from PEM to DER format:
openssl x509 -in cert.pem -out cert.der -outform der
// Load the certificate into the fs-verity keyring. This step MUST be
// done on the host kernel.
keyctl padd asymmetric '' %keyring:.fs-verity < cert.der
// Now set up fs-verity on the test file:
fsverity sign file file.sig --key=key.pem --cert=cert.pem \
--salt 12345678
fsverity enable file --signature=file.sig --salt 12345678
BUG=b:141632062
TEST=See above
Change-Id: Ied7106cfbd2919f1f0c7f605166769d4916925b0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3141298
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
A new command line parameter to specify privileged UIDs.
If the requester UID is privileged, PassthroughFs uses D-Bus to set
quota project ID.
BUG=b:190791826
TEST=build
Cq-Depend: chromium:3129049,chromium:3129048
Change-Id: Ie27f200e8c651be6a5503f69e7b784c5e8f968ea
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3014623
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Enable with `--cras-snd`.
Verified:
Basic playback and capture
Missing features:
* Getting chmap/jack/stream info from CRAS. They are hardcoded for now.
* Jack connect/disconnect notifications from CRAS
* Reporting latency bytes to the driver. It is currently hardcoded to 0.
BUG=b:179757101
TEST=`aplay` and `arecord` inside a debian img with a 5.10 kernel built
with virtio snd support. Launched with crosvm on rammus/kukui/hatch
Change-Id: I240000a92418b75b3eb8dcd241ff320214b68739
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2777991
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Woody Chow <woodychow@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Rather than using .find().is_none(), use !.any() to fix a new clippy
warning.
BUG=b:197251702
TEST=bin/clippy # with rust-toolchain = 1.54.0
Change-Id: I7e3de6b8e864f74300956c43dffaa033c58b7eb0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3108617
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Allen Webb <allenwebb@google.com>
mem::take() can be used in place of mem::replace() when replacing with
the default value, fixing a new clippy warning.
BUG=b:197251702
TEST=bin/clippy # with rust-toolchain = 1.54.0
Change-Id: I7289515eece30b9e294046930aa863a1ceab4de4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3108616
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Fixes a new clippy warning with Rust 1.54.0.
BUG=b:197251702
TEST=bin/clippy # with rust-toolchain = 1.54.0
Change-Id: I42cf6e380900ea4bb245629b56b0be5c75e2099d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3108615
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Allen Webb <allenwebb@google.com>
Pull the duplicated first statement out of the IRQ triggering sequences
to placate clippy's new warning.
BUG=b:197251702
TEST=bin/clippy # with rust-toolchain = 1.54.0
Change-Id: I8cd8577af35990522e198f97f3a666ad6730e31b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3108614
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Instead of checking each item for Some/Ok-ness, filter down to just the
desired items using flatten() on the iterator.
BUG=b:197251702
TEST=bin/clippy # with rust-toolchain = 1.54.0
Change-Id: I80db12c36f41e76f5dff6c30299a3f5d3745f578
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3108613
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Allen Webb <allenwebb@google.com>
Tree-wide cleanup of new clippy warning in Rust 1.54 that warns about
needless borrows:
error: this expression borrows a reference (`&...`) that is
immediately dereferenced by the compiler
https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow
BUG=b:197251702
TEST=bin/clippy # with rust-toolchain = 1.54.0
Change-Id: Ib702ec524d4623d264a00ec11dbc2150c411a67b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3108321
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
For vfio-pci devices created during vm setup period, they have the same pci
address as host.
For hotplug in vfio-pci device, caller should assigh the bus number,
so it could be associated with a pcie root port or pcie downstream port, but
devfn should be 0, as pcie root port driver scan it children device at devfn=0.
BUG=b:185084350
TEST=Boot a vm with passthrough device and check its function
Change-Id: Ia314cb74b15de374de540e440a91374a6538af54
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955568
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Pci BusNumber is allocated by guest kernel, the BusNumber should be 0
for all the integrated pci devices and vfio-pci device, but pci bridge
and vfio-pcie device may have BusNumber > 0, so caller should know its
device BusNumber and pass it into allocate_pci() and get the desired
PciAddress.
BUG=b:185084350
TEST=None
Change-Id: I3cb18212e6c168c047f655a5f425abdeccbaae55
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954678
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
PcieRootPort is used to notify hotplug event into guest,
so implement HotPlugBus trait on it.
BUG=b:185084350
TEST=Boot a guest with pcie root port and check its status
Change-Id: Ide110d107422fa784bd8de0aaa87b319c786ef28
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954677
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Pcie root port implements pcie cap register, but it is wrapped as a pci
bridge to VM, the pci bridge implements PciDevice trait.
BUG=b:185084350
TEST=Boot a guest with pcie root port and check its status
Change-Id: I739e878846f4b35d58e4d213caafe30196a27ccb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954676
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Device implement HotPlugBus trait could notify hotplug event into
guest, and such device should be added into RunnableLinuxVm, so it
could be used at device plug in and plug out.
BUG=b:185084350
TEST=Boot a guest with and without passthrough device
Change-Id: I9497f61312582483090ff708d0f37b97d7303811
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954673
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When a vfio pci device is added through hotplug in, it should be configured
at runtime and added into pci_root->devices tree, so pci_root is added
into linux.
BUG=b:185084350
TEST=Boot a guest with and without passthrough device
Change-Id: Ibcb5f4a849134f64fbceeac645bebd80d6ca72d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954672
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We can use MaybeUninit instead of heap allocation to ensure that our
buffer has the proper size and alignment. `from_reader` is used for
every message in the fs device and this saves us some unnecessary small
heap allocations.
Switch Reader::read_obj to use this method so that we don't have
multiple implementations of the same thing. This also fixes some
unsoundness in read_obj where we were creating a `&mut [u8]` out of
uninitialized data.
BUG=none
TEST=unit tests
Change-Id: I1fa66de11974e2fe3a8dfb4b7ab4b210ecf395d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3109088
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
This way we're not required to transfer ownership every time we call
`handle_message`.
BUG=none
TEST=unit tests
Change-Id: Ia0cc10c7b5431e8bb90afbc0b658efac33eef6c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3105916
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Make run_*_device() return an error instead of printing error messages
so that the caller of the functions can handle errors from each device
in the same manner.
BUG=b:195495971
TEST=cargo build
Change-Id: I1b464b8bedbe6d4e640084a2ad3b2565d11b9e07
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3099429
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
We originally created `vhost_user_devices` crate so that we'll be able
to have device executables there.
However, we decided to have vhost-user device as crosvm's subcommand.
So, we have no longer a reason to have vhost-user devices as the
separate crate. As the first step to remove the vhost_user_devices
crate, this CL move its main logic to the devices crate.
Note that we add `vhost_user_devices/src/*_device.rs` in this CL as we
need to keep the device executables for a while.
BUG=b:195495971
TEST=cargo build
Change-Id: I355b9cd35214ac0c3d8ffd6fbebc29dd7548fd61
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3070723
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Rename `devices::virtio::vhost::user` to
`devices::virtio::vhost::user::vmm` so that we'll be able to put
device-side code in the same module later.
BUG=b:195495971
TEST=cargo test
Change-Id: Ice039125bcba61555c7a58fa0ca46aaa643ee605
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3096440
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Move the definitions of SerialHardware, SerialParameters and SerialType
to the devices crate so that they'll be available for code in the
devices crate as well.
BUG=b:195495971
TEST=cargo test
Change-Id: Ieb711bdb18a8afdb28cac262a3355739604d4607
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3096439
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
One vm may have one vfio kvm file only, it could be created at vm
setup or runtime through vfio-pci hotplug, make it as global to
satisfy these two cases.
When vfio pci device is removed throgh hotplug out, the vfio group
will be removed frome vfio kvm file also, so move it into vfio.rs,
so it is could be referenced at vfio group's destroy. And
vfio group's destroy is called from vcpu thread, while vfio kvm file
is created in main thread, so use OnceCall instead of thread_local.
BUG=b:185084350
TEST=Boot a vm with or without passthrough device
Change-Id: I780c43a0ac0265f1e6f62578e134d09cbefc3e2f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3062741
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
A MSIX BAR can include both MSIX and non-MSIX registers. The non-MSIX
part of the BAR can be mmaped, eliminating unnecessary slow reads/writes
in userspace.
Add a new struct, VfioMsixAllocator, to keep track of the non-MSIX areas
of a mappable MSIX BAR. Page alignment is imposed to make sure mmap
succeeds.
BUG=b:184904868
TEST=boot Linux kernel and verify MSIX-capable passthru devices work
properly
Change-Id: I1fbf4c710f4bfaffe613d902f27e3bbb558c469e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2972489
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
num_pba_entries should use rounding instead.
BUG=b:184904868
TEST=boot Linux kernel and verify MSIX-capable passthru devices work
properly
Change-Id: I406c033f59bc50bd767116947525058b74be054f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2972488
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
For MSIX-capable PCI devices, some BAR regions are described using
VFIO_REGION_INFO_CAP_MSIX_MAPPABLE:
The MSIX mappable capability informs that MSIX data of a BAR can be
mmapped which allows direct access to non-MSIX registers which
happened to be within the same system page.
Add support for this capability so that VfioRegion stores the correct
mmaps information.
Also, fix a couple break conditions to avoid breaking out early.
BUG=b:184904868
TEST=boot Linux kernel and verify MSIX-capable passthru devices work
properly
Change-Id: Ie451b154ccd4779f1694a1ffed0bd02127f5ecdb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2972487
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Improve the log message for unexpected commands received on control
endpoints to include the type of command.
BUG=chromium:1231779
TEST=./test_all
Change-Id: I29963739bf5c5cb9fa427011fe5468a7378b67e3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3083225
Reviewed-by: Abhishek Bhardwaj <abhishekbh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
According to pci bridge spec, some registers are writable and should
be marked correctly.
BUG=b:185084350
TEST=Boot a guest with pcie root port
Change-Id: I501fa05cc9ea6b6ea02d5d8bcbb29ba291a4b49e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954675
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Some pci capability register is writable, and guest could write it
and control it(like msix control and pcie cap control), let each
pci capability returns its writable bits, so guest could write the
value into config register.
BUG=b:185084350
TEST=Boot a guest with and without passthrough device
Change-Id: Ic98a569823c762e7165f83d29ee90d2ba762dead
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2954674
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The ForceKeyFrame control is a button control, which means that it
doesn't have a value. This CL performs some minor cleanup and removes
the empty parentheses after the ForceKeyFrame CtrlVal as these are not
required.
BUG=None
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Ic86eb92e097de46ce68ed71bfe24299e07f8b78e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3064155
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Stale balloon stats results can be returned from a stats request for the
following reasons:
* The initial stats buffer from the guest is posted to the
balloon_host_tube without a request.
* Balloon stats requests can fail because the balloon device isn't
completely set up yet; writing a stats request to the tube without
reading the response.
* Balloon stats requests can time out, returning an error. When the
balloon stats are eventually computed, they will be queued to the tube
without a read to consume them.
Possibly other reasons too.
This CL fixes this by adding an id to the balloon stats request. The id
is then returned with the computed stats. When consuming stats results
from the balloon_host_tube, we check that the ID is the one we expect,
if not, we keep reading from the tube until we do.
BUG=b:189282316
TEST=tast run dut multivm.Lifecycle.arc_host
Change-Id: I08e50196a45383b30c9e510b3bacbe32888aef80
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3056310
Auto-Submit: Charles William Dick <cwd@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Charles William Dick <cwd@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Hikaru Nishida <hikalium@chromium.org>
VIRTIO_IOMMU_F_TOPOLOGY is not needed as DT/VIOT are the preferred
methods for vIOMMU discovery.
BUG=b:181736020
TEST=boot Linux kernel and verify passthru devices work properly with
iommu=on
Change-Id: I07b2924a8a903ccd5def817af6f7e74c8eb91162
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2976056
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Add generate_acpi() to traits PciDevice and VirtioDevice to allow each
device to generate its ACPI table elements. The default implementation
is to generate nothing.
BUG=b:181736020
TEST=boot Linux kernel
Change-Id: I9d8d2cb81d571e608a45e7fecb82c3f0922d0898
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2846423
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This CL adds support for the VIRTIO_VIDEO_CONTROL_PREPEND_SPSPPS_TO_IDR
control to the virtio encoder. When this control is enabled SPS and PPS
NAL units are prepended to IDR frames, to improve the resilience of
encoded video streams.
Note: Currently the libvda backend always prepends SPS and PPS NAL
units to IDR frames. This behavior can not be disabled, so when
querying this control it will always be reported as enabled. Trying to
set the control to disabled will result in an error.
BUG=b:161495502
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Cq-Depend: chromium:3058721
Change-Id: I2a53b635553cfbdbc483c4d678f124953721dba0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3060098
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
This CL adds support for dynamically changing the peak bitrate in
addition to the target bitrate. This is done by adapting the
request_encoding_params_change function to use the new Bitrate data
structure, similar to the changes done in the Chrome
VideoEncodeAccelerator.
BUG=b:190336806,b:181514834
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Cq-Depend: chromium:3032331
Change-Id: Id0fd3fa2b3d818c8880d4a02a96f84b218b19cef
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3033225
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The feature was never finished (crbug.com/911799), but adds a
build-time dependency on the trunks proto in platform2.
BUG=b:193267897
TEST=cargo build with and without tpm feature
Change-Id: I7299ba0779bb04ebca6284cfd11873e99500c993
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3043491
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
fs/worker.rs and fs/mod.rs were still using the old std::sync::Mutex
version instead of the crosvm-specific wrapper sync::Mutex
BUG=b:179636297
TEST=build crosvm and run shared-dir with virtio-fs
Change-Id: I773a885fd0ef35e25bc7a090f067d8a6f60636da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3058837
Auto-Submit: Morg <morg@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Morg <morg@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This CL adds support for the VIRTIO_VIDEO_CONTROL_BITRATE_PEAK control
to the crosvm encoder. This control allows configuring the peak bitrate
used when encoding a video. The peak bitrate is only used when the
bitrate mode is set to VBR (variable bitrate), and is ignored for CBR
(constant bitrate).
BUG=b:190336806,b:181514834
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420
Cq-Depend: chromium:2946469
Change-Id: Ie513b474f48f09a710a68c9f06111e0fc6627aa6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2944321
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
... by not holding locks while data is being copied around, but only
when the buffers are being allocated.
BUG=b:174713663
Change-Id: I558e14422eeff690c09f031f6c5564ee7de21e39
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2994806
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When VIRTIO_GPU_BLOB_FLAG_CREATE_GUEST_HANDLE is not set, the check
should not be applied. This is also more consistent with
GpuCommand::ResourceAttachBacking.
When VIRTIO_GPU_BLOB_FLAG_CREATE_GUEST_HANDLE is set, the check may not
be correct because upstream kernel made the limit configurable recently
https://patchwork.freedesktop.org/patch/438905/
It should be better to just remove the check and let the kernel does the
validation.
BUG=b:194314538
TEST=huge allocations
Change-Id: I536f44b257a96f7a52a0bc88fc2b63e0e2a701f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3059400
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Chia-I Wu <olv@google.com>
At crrev.com/c/2719245, we postpone sending the decoded frames until
receiving the buffer. However, we should also keep the order between
decoded frames and the flush complete event. This CL handles both
event response together to preserve the order.
BUG=b:168750131
BUG=b:192523692
TEST=android.mediav2.cts.CodecDecoderSurfaceTest#testFlushNative
TEST=android.media.cts.AdaptivePlaybackTest
Change-Id: I9184790c855c7d60455d1f71daad768200adc468
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3005181
Auto-Submit: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The `# ignored by ebuild` tag will remove the path to libcras_stub and
allows crosvm to be built with the actual libcras implementation.
This allows all other platforms to build without depending on
`third_party/adhd/cras/client/libcras`, which is a prerequisite for
externalizing crosvm.
An empty libcras_stub crate is provided to keep cargo happy in external
builds.
To build with cargo against libcras, the setup_cros_cargo.sh script
can be used.
BUG=b:191511078
TEST=Tests in crosvm and cros_sdk both pass:
$ ./test_all
$ cros_run_unit_tests --package=crosvm
Cq-Depend: chromium:2993483
Change-Id: I86aad23a86c78e580c1724fb311f870b25d6b09e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2988154
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
This CL adds support for the VIRTIO_VIDEO_CONTROL_BITRATE_MODE control
to the crosvm encoder. This control allows configuring the bitrate
mode used to encode a video.
Possible values are:
- VIRTIO_VIDEO_BITRATE_MODE_VBR (Variable bitrate)
- VIRTIO_VIDEO_BITRATE_MODE_CBR (Constant bitrate)
BUG=b:190336806,b:181514834
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Cq-Depend: chromium:2946469
Change-Id: Ic8461e746884620cd426c1b562724e4120fe2129
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2944317
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
The VioSClient object has no reason to keep track of stream states,
except maybe to validate operations, but for that it can simply rely on
the sound server to do it for it.
BUG=b:174713663
Change-Id: Ia0bb1675f4cbfb2714feebe63aec8d75e54c1588
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2986401
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
CL crrev.com/c/3005194 introduced changes to the encoder to allow
dynamic framerate changes even when there are already resources queued
in the input or output queue. As a side effect the encoder is only
recreated if any parameters besides the framerate change.
Unfortunately the above checks assumes that changing the framerate will
never influence any of the other parameters, which isn't always
correct. The requested H.264 level is adjusted to conform to the
minimum requirements for the selected bitrate and framerate. We can't
dynamically adjust the H.264 level during encoding, but as long as we
don't have any resources queued yet we can recreate the encoder to make
sure the H.264 level is properly adjusted if required.
BUG=b:192623395,b:192419592,b:193947502
TEST=android.media.cts.MediaRecorderTest#testProfileAvcBaselineLevel1
Change-Id: Ie02e30a5b6fb82b9b62e88ae3ab75c8ef42f3844
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3037296
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This reverts commit c6554e9c7e.
Reason for revert:
`time tast run mycros arc.Boot.vm` will always halt at
```
Waiting for Android boot
Waiting for initial ARC process
```
till timeout.
Original change's description:
> virtqueue: Try to further reduce unnecessary interrupts
>
> Try to reduce unnecessary interrupts by updating `signalled_used` every
> time we check `used_event` rather than only when we actually write to
> the eventfd.
>
> This technique is lifted out of the vhost_add_used_n and vhost_notify
> methods in drivers/vhost/vhost.c in the kernel and the variable names
> are changed to more easily compare the two implmentations.
>
> This combined with the other notification suppression changes give a
> performance improvement of ~10% across all storage devices in the
> blogbench benchmark.
>
> BUG=none
> TEST=vm.Blogbench.{p9,block,virtiofs}
>
> Change-Id: I618767e4c36ecae607b7641e54a029c25583844d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026691
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
BUG=b:194452080
TEST=time tast run mycros arc.Boot.vm
Change-Id: Ib7511dec3e0df26be54616f20226ded598fc8a37
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3051292
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Try to reduce unnecessary interrupts by updating `signalled_used` every
time we check `used_event` rather than only when we actually write to
the eventfd.
This technique is lifted out of the vhost_add_used_n and vhost_notify
methods in drivers/vhost/vhost.c in the kernel and the variable names
are changed to more easily compare the two implmentations.
This combined with the other notification suppression changes give a
performance improvement of ~10% across all storage devices in the
blogbench benchmark.
BUG=none
TEST=vm.Blogbench.{p9,block,virtiofs}
Change-Id: I618767e4c36ecae607b7641e54a029c25583844d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026691
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Now that the get and set methods have the proper memory barriers it
should be safe to re-enable this.
BUG=none
TEST=crostini.Basic.buster_stable; reboot arcvm in a loop for 75
iterations without observing a hang
Change-Id: I03271d838e31ad091536163359836bead7e00178
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026690
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit e470ef9933.
Reason for revert: possibly breaks critical test, in turn CQ.
Original change's description:
> devices: irqchip: add need_halted function
>
> This allows irqchip implementations to specify whether they need to be
> notified via the halted() function when the vCPU encounters a HLT
> instruction.
>
> All of the current in-tree irqchip implementations do nothing on
> halted(), so this will always return false for now, but a fully
> userspace irqchip would need these notifications.
>
> Querying this function will allow the hypervisor code to determine
> whether disabling VM exits on HLT instructions is allowed.
>
> BUG=b:181106085
> TEST=test_all
>
> Change-Id: I433fe208d125dcd14e7100ce5aff37474b423a83
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2937304
> Reviewed-by: Colin Downs-Razouk <colindr@google.com>
> Reviewed-by: Zach Reizner <zachr@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Bug: b:181106085
BUG=b:194452080
Change-Id: I755fc732e79a56f0306819e23ba9bd6c840dc927
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3045583
Commit-Queue: Leo Lai <cylai@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leo Lai <cylai@google.com>
Auto-Submit: Leo Lai <cylai@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
The devices to be notified on resume are unrelated to the functionality
of Bus, which is looking up devices in an address space. Additionally,
each Bus instance had its own list of devices to notify, although in
practice, only the one in the I/O bus was used.
Move the resume_notify_devices list into RunnableLinuxVm instead.
BUG=None
TEST=Boot Crostini on x86 and arm
Change-Id: I72c629c6d6589c4a9350831c8a076c5c0c9f9aeb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3043489
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
This allows irqchip implementations to specify whether they need to be
notified via the halted() function when the vCPU encounters a HLT
instruction.
All of the current in-tree irqchip implementations do nothing on
halted(), so this will always return false for now, but a fully
userspace irqchip would need these notifications.
Querying this function will allow the hypervisor code to determine
whether disabling VM exits on HLT instructions is allowed.
BUG=b:181106085
TEST=test_all
Change-Id: I433fe208d125dcd14e7100ce5aff37474b423a83
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2937304
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This should reduce the number of interrupts generated by the device as
well as the number of vm exits triggered by the guest for notifying the
device.
BUG=none
TEST=crostini.*; reboot arcvm in a loop for 30 iterations without
observing a hang
Change-Id: Iea4a59092ba6306de9eecbb7722d0ae356183272
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026689
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
In order to enable the VIRTIO_RING_F_EVENT_IDX feature, devices need to
keep processing the queue until it is empty as the guest may not send
any more notifications until the device has processed all pending
messages.
Change the process_queue method to process all messages in the queue.
BUG=none
TEST=????
Change-Id: I7df56111ad99bc7511c685ecafc051aef077b34e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026688
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When the VIRTIO_RING_F_EVENT_IDX feature is enabled we will
automatically update avail_event when a descriptor from the queue is
popped. Having update_int_required set this to a different value means
that it would keep going back and forth.
BUG=none
TEST=crostini.Basic.buster_stable
Change-Id: I9098259c306cf19c034656169ee0e70ad69d1c64
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026687
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Have all devices trigger interrupts via the Queue rather than directly.
This way we can skip sending the interrupt entirely when notification
suppression features have been negotiated with the guest kernel.
BUG=none
TEST=crostini.Basic.buster_stable
Change-Id: Ica6f978127aa648fd983f641518940d7a857916f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026686
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This is needed because virtio IOMMU may not allow writes to mapped
memory if VIRTIO_IOMMU_MAP_F_WRITE flag is not set in driver MAP
request.
BUG=b:181736020
TEST=--vfio=/sys/bus/pci/devices/0000:00:14.0,iommu=on
Change-Id: I2c101410594782f1b66b3f6ae527d4a7621b7496
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757279
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
In VT-d, the IOMMU hardware can translate guest physical address that
is no more than MGAW (Maximum Guest Address Width) which is reported
from the VT-d Capability register.
We pass this information to the guest IOMMU front driver so that it
can allocate appropriate IOVA.
VT-d indicates that "implementations must support MGAW at least equal
to the physical addressability (host address width) of the platform".
Thus we take the Physical Address Bits that is reported by
CPUID.80000008H as the minimum MGAW.
BUG=b:181736020
TEST=--vfio=/sys/bus/pci/devices/0000:00:14.0,iommu=on
Change-Id: I26a421ea2e7dd893d413d63ab313721cfdf0b5c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757278
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
A completed fence callback is set in Rutabaga. When the callback
is executed, the descriptor associated with the fence is immediately
marked as used and the control queue is signalled.
As of now, the callback is still called in the main worker thread
when poll_fence() is executed, but once we enable the async callback
feature in virglrenderer, the callback might be called from another
thread. This is the reason everything is protected with mutexes.
The completed_fences hash map keeps track of the latest completed
fence for each context to avoid any race condition.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Change-Id: I6f3f55d21b7f4722721bdc2b16da1b39bae4ff7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2845984
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
These values are either written by the device and read by the guest or
vice versa. Either way, since these could happen simultaneously on
separate cores we need fences to prevent the CPU from re-ordering loads
and stores.
"get" methods use acquire-load semantics while "set" methods use
release-store semantics. This also matches what we were already doing
for "get_avail_index" and "set_used_index".
With this it should be possible to re-enable the check for
VIRTIO_AVAIL_F_NO_INTERRUPT but we'll do that in a separate change since
we need these changes no matter what.
BUG=none
TEST=crostini.Basic.buster_stable
Change-Id: I2d52c92fbd7ab0fe6d64693d60f46d0dec4b4cb5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026685
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Currently changing the framerate during video encoding will always fail
once resources are queued on the input or output queue. This CL makes
adaptations to the crosvm encoder to fix dynamic framerate changes.
To support dynamic parameter changes the crosvm encoder will now
properly check whether values actually changed, and only report an
error if we're trying to change static parameters during encoding (such
as the output format). As a side effect this greatly reduces the amount
of times the Chrome encoder is recreated; parameters are configured
one-by-one through virtio and each parameter change requires us to
initialize an encoder, as we only know the coded size after the
initialized encoder calls the RequireBitstreamBuffers() callback.
BUG=b:192623395,b:192419592
TEST=android.media.gts.RtcVideoCodecTest#testDynamicFramerateChangeVp8
Change-Id: I20e60013dbdf9f4b139c795f503c6a08a7d3e6e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3005194
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Add vhost-user device of mac80211_hwsim that connects to
the unix socket of vhost server for mac80211_hwsim for
emulating Wifi device at crosvm.
Add cmdline flag --vhost-user-mac80211-hwsim for
specifying unix socket path to connect.
BUG=b:182577273
TEST=At Android's source tree,
lunch aosp_cf_x86_64_phone-userdebug &&
m PRODUCT_ENFORCE_MAC80211_HWSIM=true &&
launch_cvd \
--vhost-user-mac80211-hwsim=${VHOST_SOCKET_PATH}
Check AndroidWifi appears at wifi connection settings.
Change-Id: I33e5d8fed59c84d3848bfe24d935ce973d758e12
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3020848
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: JaeMan Park <jaeman@google.com>
This change is a refactoring of the initial Console backend
implementation to make use of already-existing serial console
initialization code. It allows us to leverage from already-existing code
for alternative input/output files.
BUG=b:192517623
TEST=run crosvm with vhost-user-console and no changes are detected
Change-Id: I433cad1fac8f415173aee06b8ad1c96eb8f6690b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3023804
Commit-Queue: Morg <morg@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Auto-Submit: Morg <morg@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
- Adds the ability to start/stop background thread on demand
- Changes the way audio data is injected to not assume how the data is
kept by users of the api
- Adds new functions for jacks and chmaps
- Rename constants to match the name used in the virtio-snd spec
BUG=b:174713663
Change-Id: Ie0fe20747a26122258cb63bac09ec0347f13ecc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983388
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
page_size_mask in IOMMU device configuration contains the bitmask of all
page sizes that can be mapped. It's good to get this information from host
VFIO/IOMMU driver, so that the guest is able to issue DMA mapping requests
with page size as large as possible to reduce the number of DMA map requests.
BUG=b:181736020
TEST=--vfio=/sys/bus/pci/devices/0000:00:14.0,iommu=on
Change-Id: I4c003473a48688cbdde0ff162dd0b414926d5c88
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757277
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
By default virtio-IOMMU is disabled. It can be enabled per pass-through
device. Sample command lines:
default: virtio IOMMU disabled on pass-through device:
--vfio=/sys/bus/pci/devices/0000:00:02.0
Explicitly disable virtio IOMMU:
--vfio=/sys/bus/pci/devices/0000:00:02.0,iommu=off
Enable virtio IOMMU on the desired pass-through device:
--vfio=/sys/bus/pci/devices/0000:00:02.0,iommu=on
BUG=b:181736020
TEST=passthru one device with iommu=on
TEST=passthru two devices with iommu=on from different VFIO group
TEST=passthru two devices with iommu=on from same VFIO group
TEST=passthru one device with iommu=on and another device with iommu=off
Change-Id: Id74d2210f774a90ba5e83671e76e061cb8fec758
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757276
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
This is to backport virtio IOMMU backend driver from Cloud-hypervisor,
which emulates an IOMMU device to manage DMA from one or more endpoints
in the guest.
Some differences from the Cloud-hypervisor implementation:
- Simplified the mapping between IOMMU driver and Vfio container
- This port supports multiple endpoints attach to same IOMMU domain.
BUG=b:181736020
TEST=bin/clippy, functional tests specified in the patch
"iommu: enable virtio IOMMU driver"
Change-Id: I3db3b46a72e82908459e91a4e6852a335c606db1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2846421
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
In preparation for virtio IOMMU support, implement global variables
IOMMU_CONTAINERS and NO_IOMMU_CONTAINER to hold the VFIO containers
for VFIO devices with or without IOMMu enabled respectively.
Also implement vfio_get_container()help create VFIO container based
on the more complicated policies.
- all VFIO devices without attaching to virtio IOMMU devices share
one VFIO container.
- for IOMMU enabled devices, one VFIO container manages all devices
under one VFIO group.
- we don't support multiple IOMMU groups set to one VFIO container.
Currently don't see an user case for this.
BUG=b:181736020
TEST=unit tests.
Change-Id: I44d792cbc8ca9696c1da54c571aad1b94c7f665d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2976054
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
One KVM_DEV_TYPE_VFIO instance may be created per VM. Currently this
device is created from VfioContainer::init(), which makes it not able
to create multiple vfio container.
This patch creates the KVM_DEV_TYPE_VFIO virtual device before creating
any VfioContainer or VfioDevice instances, and passes it into the
VfioDevice constructor where it's actually used. In this way, it's
possible to create multiple VFIO containers
BUG=b:181736020
TEST=passthru multiple devices and create more than one VFIO containers
Change-Id: I4b4e4941363efa91f2217af385f4f00eadd041c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2976053
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Long-term libvda will be replaced with an implementation that can
function outside of ChromeOS.
In the meantime thes allows crosvm to be built externally and pass
clippy with all features enabled.
BUG=b:191507399
TEST=Tests in crosvm and cros_sdk both pass:
$ ./test_all
$ cros_run_unit_tests --package=crosvm
Cq-Depend: chromium:2989315, chromium:2986403
Change-Id: Ic37bda4426d69d16cb4bc0d7ba6f81052f6f2f59
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983505
Tested-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Add a new vhost-user device binary implementation.
Example command to launch the device:
vhost-user-console-device --socket test
BUG=b:179755825
TEST=run crosvm with vhost-user-console and the console comes up
Change-Id: I4bb06e058523b73cb01fbe993e0fe7f9e4ee6423
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2951187
Auto-Submit: Morg <morg@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Morg <morg@chromium.org>
This adds a vhost-user console to the vmm, which will be enabled by
`--vhost-user-console <socket path>` option.
BUG=b:179755825
TEST=launch crosvm with --vhost-user-console and connection happens
Change-Id: I6339c6cde3a221fd3e6a1652474e17344c73d6d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2814058
Auto-Submit: Morg <morg@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Morg <morg@chromium.org>
The output buffers must all have the same pixel format, therefore it
doesn't make sense to pass it with each buffer we import. Instead, pass
it alongside the number of output buffers (before any buffer is
imported) and let the backend remember it.
BUG=b:161774071
BUG=b:169295147
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I1890ad24f9874ed3c674a7bdf7d4be303ba24e92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983094
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Methods that mutate the backend should take a mutable reference to self.
This problem was not apparent with the VDA backend since libvda's
methods themselves are not mutable, but this will cause issues with
backends that include more of their own data.
BUG=b:161774071
BUG=b:169295147
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I61cc64b6cbb9f4d1633c6a0acc188bbfc8dd0c54
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983093
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This is useful for e.g. unit tests.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: Ica409926c9da6c788a60134fa3f609db97f4aaa4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983092
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
We are using similar structures for describing the planes of a frame in
the decoder and encoder. Consolidate them into a single structure
accessible from the shared format module.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I289c896e022cbb0952a1f2be626b3f8a6caaf13e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983091
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The interface to return the event pipe for a backend currently requires
a &File to be returned, which is not very appropriate since the file
only serves as a proxy to the pipe's file descriptor.
Although libvda uses this structure to return its event pipe, this won't
be the case for all backends, so change the interface to return a
non-owned Descriptor, which is more generic and suitable to the task.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I73dc66ba59e023a77d7b8e0efe533ec7805cf441
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983090
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Cuttlefish's streaming server, which acts as a Wayland compositor
in order to receive display framebuffers from Crosvm, needs some
mechanism to tell which Wayland surface corresponds to which display
(a "display" is a "scanout" in virtio-gpu terminology).
Wayland object ids can not be directly used for this as all Wayland
objects share a single global id space (so the first created Wayland
wl_surface surface object may have id = 15).
Previously, the case of unchanging displays was handled by enforcing
the creation order of surfaces within Crosvm so that Cuttlefish's
streaming server (which is a Wayland compositor) could assume the
creation order corresponded to the display order. However, this still
experienced issues (b:186580833) when surfaces were destroyed and
later recreated when handling `set_scanout(..., resource_id = 0)`
commands.
There is also an ongoing effort to support adding and removing
displays at runtime in (see aosp/1671968) which experiences the
same issue. When surfaces are arbitrarily created and destroyed,
Cuttlefish's streaming server has no way to determine which Wayland
surface corresponds to which display.
To solve all of this, this change introduces an extension to allow
Wayland clients (Crosvm) to attach additional metadata (scanout_id)
to Wayland objects (surfaces) so that Wayland compositors (Cuttlefish's
streaming server) can exactly determine which surfaces correspond
to which displays. I will attempt to upstream this protocol (tracked
in b:191901112).
BUG=b:188904670
BUG=b:187351899
BUG=b:191901112
TEST=launch Cuttlefish with single display
TEST=launch Cuttlefish with multiple displays
TEST=launch Cuttlefish and hotplug some displays
Change-Id: I2aa4b714a49e4d85b6a3c705ba0d5bc1720b838e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2909903
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
The new cras_backend to be implemented will use these functions
BUG=b:179757101
TEST=cargo test
Change-Id: Ie1777d79a16303e562740b2e02f6b509fab4ef92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2993704
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Commit-Queue: Woody Chow <woodychow@google.com>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Updates virtio-gpu frontend to track multiple
scanouts and the resources set for those scanouts.
Adds a --gpu-display command line arg to avoid having
to create a very complicated --gpu string.
BUG=b:173523402
TEST=launch Cuttlefish w/ multiple displays
TEST=(see change series at aosp/1652814)
Change-Id: I73174c11f35f865b8b67ae77d8169d6812f85535
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2836265
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
use_output_buffer() can fail, in which case we won't have processed any
buffer. Increase our ID counter only if we are confident a buffer with
the assigned ID will eventually be delivered.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I37ad68059854182795ff631b3816614058444900
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983088
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
It allows Rutabaga library users to set a fence callback on the
component builder or while creating a context. The handler is
called when a fence is signaled as completed and could
be executed from another thread.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Change-Id: Ia9176bf2f0822a0076bed6a7a09e709b426aa620
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2845982
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
The vhost user block device can be started as follows:
```
cargo run --features=block --bin vhost-user-block-device -- \
--file vhost_test.img --socket /tmp/vhost_user_blk.socket
```
Or a read only disk:
```
cargo run --features=block --bin vhost-user-block-device -- \
--file vhost_test.img:read-only --socket /tmp/vhost_user_blk.socket
```
And tested with a crosvm instance as follows:
```
cargo run -- run --disable-sandbox --rwroot debian.ext4 \
-p "console=hvc0 root=/dev/vda rw" \
--vhost-user-blk /tmp/vhost_user_blk.socket bzImage
```
The vhost-user-block device will appear as /dev/vdb.
BUG=b:179755342
Change-Id: Ie8c10dad8978e0f4a381e06576239df1e8174db5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2948103
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
These functions will be used from the `vhost_user_devices` code to run
vhost-user block.
Change-Id: I8351a9b0ced1e36a0543096c59560bbd14dba06a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2948102
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Added preliminary version of keyboard and pointing device routine
for wayland implementation. The pointing input is wired as a multi
touch device. Due to the fact that wayland client is callback based,
all the necessary incoming events are serialized and stashed in the
temp circular buffer and then processed afterwards from the main event
loop.
Known issues:
1. Mouse input can't be properly wired inside the guest as a mouse
device without pointer locking, but this is not what we want. The
approach emulates it as a multitouch device, but, of course, it
implies limitations in functionality. Limitations include cursor
in the VM that doesn't move in unison with the host cursor.
2. I kept the mouse cursor surface since it's not decided yet which
approach for handling pointing input device will be used (see #1).
Removing the mouse surface in the guest would remove the lagging
guest cursor. The alternatives to the multi-touch device are:
"- Relative mice (e.g. a typical PC mouse). These are relative
devices, meaning they send deltas from the current cursor
position. Some apps like games rely on these events.
- Touchscreens (multitouch, single touch). These are absolute
devices, and are much easier to implement seamless guest/host
input for.
- Touchpads (these are absolute devices). I'm not sure these are
really compelling for any use case." -nkgold@
3. This code is for POC purpose only, so there are still lot of minor
issues and negligence in it.
Looking forward for your comments and proposals.
BUG=b:177939148
TEST=crosvm $ARGS \
--display-window-keyboard \
--display-window-mouse \
--gpu=3d,glx=false,egl=true \
--wayland-sock=/run/user/1000/wayland-0 \
$OTHER_ARGS
Change-Id: If4a9b73b8da4e0cc52fa619bbd6e5588ccdb7874
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2688439
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Although the current crosvm won't change call fd once it's set, the
vhost-user allows it and QEMU does so.
So, we wrap CallEvent with `Arc<Mutex<...>>` so that we can replace the
fd later.
BUG=b:190450677
TEST=run with QEMU using vhost-user net device
Change-Id: I16cbcd843e370aeaf6b28c8a520b3bfa4a35286b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2950027
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The features bit manipulation was already duplicated and will be needed
again in the vhost_user implementation.
Change-Id: I8a75341053feac8c222c2d959370aa9f32a82258
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2948101
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
There is a desire for Wayland and possibly other display backends to
reasonably handle input. Move the event device logic inside the X11
backend up to the common layer to prevent duplication.
The common layer also keeps track of surfaces and external memory
objects to make this easier. The GpuDisplaySurface/GpuDisplayMemory
traits are introduced in case the common layer needs to perform
compositor specific operation.
BUG=b:173630595
TEST=compile and run with X11
Change-Id: Ied060a7cc216ac6c084030aad1fc839c022a3395
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2852523
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
It is inherently racy to wait on a Condvar without first checking if the
condition is already satisfied. Additionally, Condvar::wait can
spuriously return early even when the condition is not satisfied so it
is necessary to check it in a loop.
BUG=b:190444698
TEST=cargo test
Change-Id: If7703c6e8b9015df3c463147f3ad2a1c10c3a7ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2944323
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The resource bridge is only used by 2 methods of Device, so it makes
little sense to have worker maintain it and pass it around. Make it a
member of Device instead.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: I5d305177b5fa6d86ee49d404a0fd65ba573578a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932301
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This removes the need to pass the descriptor map as an argument of all
Worker's methods.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: Ide8d1a858bb09f1098a38c49643fdf365ae7aec1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932300
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The command and event queues are not replaced throughout the Worker's
life, and their ownership is given to it when run() is invoked. Make
them members of Worker so we don't need to pass them around with each
method call.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: I92441a8be5e9dbc2fdaddc1546632ea404de0aaa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932299
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
A given net device should expose the minimum MTU of all its
tap interfaces. This ensures that the guest won't inadvertently
produce frames that the host will have to drop, if a lower MTU
is in use on the host (common with cellular links).
BUG=b:171098377
TEST=create tap with MTU < 1500 and start crosvm
Change-Id: I6add14b532e4c2d070d2fe4410272421afc1303f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2917620
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
All the members of Worker are currently public to allow users to
build them inline. Use a constructor instead so all members can be made
private.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: I093d7e9b9183b46c7ffe6717199e0ed654b6236e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932298
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Support running the wl device as an out-of-tree process. Unlike other
vhost-user devices, this one uses a second socket for additional
wayland-specific messages between the device and VMM. Since
virtio-wayland is not a standardized device and it's likely it will be
merged into the gpu device, it's not worth the effort to try to
incorporate the wayland-specific extensions into the regular vhost-user
protocol.
BUG=b:179755841
TEST=start a crostini vm with a vhost-user-wl device and play
gnome-mahjongg
Change-Id: I455d32393426aff2acd392092ff82f6cc970d903
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2919156
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
BUG=b:179755841
TEST=start a crostini vm with a vhost-user-wl device and play
gnome-mahjongg
Change-Id: I4bbb084eed972e783908b23b37443ebb2f4847ae
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2919155
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
We can directly call pop() in write_event() and return an error if no
item is available. pop() actually does exactly what we were doing, but
makes the code a bit shorter.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: I893666de0132f573164687e78fe0ac4e8996da71
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932297
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This will make it easier to run the virtqueues from a vhost-user
process.
BUG=b:179755841
TEST=Start crostini and play gnome-mahjongg.
Change-Id: Ic4132a66ef7718fe85307f5d743110645288967a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2910215
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Currently, the encoder returns an error if no buffer was available to
signal the end of stream after a flush had completed. Fix this
non-compliant behavior by just waiting until the next output buffer is
queued by the client, and returning that buffer immediately to signal
the end of stream.
Since this behavior is also needed for the decoder, and is a workaround
for libvda's inability to signal the last buffer of a stream, make that
functionality available through a new EosBufferManager struct that can
easily be reused and removed.
BUG=b:168750131
BUG=b:186374269
BUG=b:161774071
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch-arc-r.
TEST=android.mediav2.cts.EncoderProfileLevelTest passes 100 times on
eve-arc-r.
Change-Id: Iebac5f3342393cc6763dbeedda041cf0c3983085
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2914232
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
For cross platform purposes, we need to be able to switch out the
implementation of rust-vmm/vhost. To make this easier, this CL moves all
VMM side calls into that crate into VhostUesrHandler. (The device side
calls are already in DeviceRequestHandler, so no further change is
needed there.)
Note that vmm_vhost::vhost_user::message::* are fine to use directly for cross
platform purposes.
BUG=None
TEST=builds
Change-Id: I5252e8522efa61dc773a74889915ec9a7ef58ec5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2913139
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Move all the block related code to a module under virtio.
This is deemed better than manual namespacing with block_....rs
Change-Id: I8543ef0345011679e02d3762ff94729b0a4eb1f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2915763
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
It has taken a while to get the non-async code removed so make the
shared parts explicitly shared instead of duplicated.
Change-Id: I58d092eefad37bc23da80f0ecac394bb6155efc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2910993
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
The seq_socket_send() function only requires a non-mutable reference;
drop the mut.
Fixes clippy warning "the function `seq_socket_send` doesn't need a
mutable reference".
BUG=None
TEST=bin/clippy
Change-Id: I517a8d782601f33653db33c201666707beddd5ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2885787
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Make the act of dequeueing the EOS buffer a method of its own, so it can
be invoked from different points of the code.
BUG=b:168750131
BUG=b:186374269
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch-arc-r.
Change-Id: Ic8c2cc118df234093ae15aada0737063c8ad80c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2914231
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Add a default-enabled "usb" feature to allow compiling out the emulated
USB controller and host device provider when not needed (e.g. for
crosvm-direct).
This reduces the crosvm-direct binary size by about 400 KiB.
BUG=b:173824333
TEST=cargo build --no-default-features
TEST=cargo build # ensure xhci controller is added
Change-Id: I1fc0eeb09c647854e5df57cd2fe7e92140256853
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2913136
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Replace an else block that just returns None with the equivalent use of
the question mark operator, and rewrite the comment that used to be in
the else block to match.
Fixes the clippy warning "this if-let-else may be rewritten with the `?`
operator".
https://rust-lang.github.io/rust-clippy/master/index.html#question_mark
BUG=None
TEST=bin/clippy
TEST=cargo test -p devices
Change-Id: Ifda6d55c16e12fc7939343757d7f2843b4df9b27
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2885784
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Fixes clippy warnings like:
using `clone` on type `...` which implements the `Copy` trait
and
redundant clone
note: this value is dropped without further use
BUG=None
TEST=bin/clippy
TEST=cargo test -p devices
Change-Id: I8c13b79b54265e5527cadcb8a2e9f54419044bcf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2885781
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add a constructor for building a VDA-backed encoder instead of requiring
the user to build one.
BUG=b:169295147
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on hatch-arc-r.
Change-Id: I712499904845b3cccb52a3e9e07c87cc1a3c92c3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891144
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The current generic Worker code is being instanciated once per kind of
video decoder and encoder. This results in quite a bit of duplication to
avoid one virtual call per device event, and also prevents us from
selecting the codec backend dynamically.
Convert that code to use a Device trait object instead for both
simplicity and flexibility.
BUG=b:169295147
TEST=cargo build --features="video-decoder"
Change-Id: I9aacd0286022d9eaa44bd57656d1959de78322a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891143
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Move the backend code into a module of the same name, to mirror the
structure used by the decoder.
BUG=b:169295147
TEST=cargo build --features="video-decoder,video-encoder"
Change-Id: I9175b054811d294c338f8b58961e4b45b10c99ec
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891142
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Move VDA code that is used by both the decoder and encoder into its own
module, so it can be easily included (or not) during compilation.
BUG=b:169295147
TEST=cargo build --features="video-decoder"
Change-Id: Ic42f94a1118fad5d60da0d5358a28a9b27c3dbc4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891141
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
These operations are backend-specific and reference libvda, so move them
out of the generic code into the backend so they can easily be compiled
out.
BUG=b:169295147
TEST=cargo build --features="video-decoder"
Change-Id: Id5b32684df8aabef0c9ee2a00977339e0191d41b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891140
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The thiserror crate is available to crosvm, so use it to make our
error handling code a bit more readable.
BUG=b:169295147
TEST=cargo build --features="video-decoder"
Change-Id: I2aacc63ffa8311d7e0bb4d1192fd0b11b4ca5d03
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891139
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Make all the encoder backend methods return a VideoError, similarly to
what the decoder does. This allows us to merge the EncoderError's enums
into VideoError and return a BackendFailure when a backend-related
problem has occured, removing references to the encoder-specific code in
the generic video code.
BUG=b:169295147
TEST=cargo build --features="video-encoder"
Change-Id: I948927ae43cbbac70c4b829fbbb314122a0b6628
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891138
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This follows the more flexible model that is used with the encoder and
removes references to libvda in the generic code.
BUG=b:169295147
TEST=cargo build --features="video-decoder"
Change-Id: Idff2894c9ea84c7bc26c5d02374c167756767a15
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891137
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
This is more idiomatic for constructors that take no arguments, and
spares us one compiler warning if decoding support is enabled without
any backend (in which case nobody creates ContextMaps).
BUG=b:169295147
TEST=cargo build --features="video-decoder"
Change-Id: I01b909eac6d443e43617f6e8cb91c6254dea5cc5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891136
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Enable support for runtime verification of number
of irqchip kernel emulated inputs, up to 120 pins.
KVM implementation supporting extended input pins shall
report KVM_CHECK_EXTENSION/KVM_CAP_IOAPIC_NUM_PINS value.
BUG=b:179648314
TEST=On systems with 24/120 pin IOAPIC kvm emulation.
Change-Id: I80063216310e427d664e3eaca3aba27e8a972cde
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2893366
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We must have read the resample event before calling
`SignalableInterrupt::do_interrupt_resample`.
BUG=b:179755448
TEST=run crosvm with net device
Change-Id: Ic4bd74d3c89cc8af69401d2c1ebc095a474fba04
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2902057
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
These functions are only used when the gpu feature is enabled.
BUG=none
TEST=`cargo build` and see no warnings
Change-Id: I8c354b0122032a6d6c57d16837d9d9e857ac03c9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891122
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Capability is read-only once it has been built, so access its members
using getter methods instead of making them public.
BUG=b:169295147
TEST=cargo build --features="video-decoder"
Change-Id: Ia5d30d94a04fc9b4e87d783c85b3ab5650ca9815
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2891135
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The current design of having the VEA instance outside of the encoder was
mandated by the use of lifetimes on libvda Sessions, which have been
removed from libvda. So it is now possible for the encoder to own its
VEA instance.
This makes sense in itself since there is no reason for the VEA instance
to also be used by someone else, but is also required to add support for
non-libvda encoder backends.
BUG=b:169295147
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on hatch-arc-r
Change-Id: Idb4356dde6124f00d87915da7da0910c7d816863
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2887526
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The libvda API has been changed and both instances and sessions do not
use lifetimes anymore. Remove them from our code or it won't compile.
BUG=b:169295147
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on hatch-arc-r
Cq-Depend: chromium:2887389
Change-Id: I9821e7f3b92b89fceb843fb0e60d041a44602f20
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2887525
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This will be used to dynamically add and remove bus ranges when the PCI
command register is updated to enable/disable memory and IO decode.
BUG=b:174705596
TEST=cargo test -p devices
Change-Id: I6bb175e0628bf598d049562700e2f55a2a62df59
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2689081
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add a vhost-user net device executable which communiates with a VMM having vhost-user net device.
Example command:
vhost-user-net-device \
--tap 10.0.2.2,255.255.255.0,12:34:56:78:9a:bc \
--socket /tmp/vhost-net.sock
BUG=b:179755448
TEST=run as a backend of crosvm with vhost-user net device
Cq-Depend: chromium:2861979
Change-Id: Ib723cdd00381b29464855378e568a9fa3de01536
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2807205
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Add `vhost_user_devices` crate which will be used to create a vhost-user
device executables.
BUG=b:185089400
TEST=cargo test in /vhost_user_devices
Change-Id: I7256d68316f7763d3ceaa65abc97663975e7608f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2822169
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This will be used to enumerate BARs when the command register is updated
to enable/disable memory or I/O decode.
BUG=b:174705596
TEST=cargo test -p devices
Change-Id: I992a2004dc58955b464467914c4ad735fb2cdd44
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2689085
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Replace the VFIO-specific MmioInfo and IoInfo structs with
PciBarConfiguration.
This will allow a unified interface for retrieving BAR information for
all PciDevice implementations; all other PciDevices use PciConfiguration
to store a list of PciBarConfiguration, so this brings VfioPciDevice in
line with those.
BUG=b:174705596
TEST=cargo test -p devices
Change-Id: Idafd8f9af2ce817877450cfb842805475785ba20
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2689084
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Extend PciBarConfiguration to support the expansion ROM BAR in addition
to the usual 6 BARs.
This will be used when adapting vfio_pci to use PciBarConfiguration.
BUG=b:174705596
TEST=cargo test -p devices
Change-Id: I712728def41b0f2981029d77c3b9d7ec065e9d9b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2689083
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
- Consistently use reg_idx to represent an index into all PCI
configuration space registers and bar_idx to represent an index into
just the BAR list. (e.g. bar_idx 0 is at reg_idx 0x10).
- Add a PciBarIndex type to make the related APIs clearer versus using
usize directly.
- Remove Default impl for PciBarConfiguration and fix up the previous
callers to fully configure the BAR type instead of depending on the
defaults.
- Omit "get_" from the names of getter functions to follow Rust
convention.
BUG=b:174705596
TEST=cargo test -p devices
Change-Id: I6921ac627f51e0df9c07585545be031ac3055a7b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2689082
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Fixes a new clippy warning ("this `else { if .. }` can be collapsed.").
BUG=None
TEST=bin/clippy
Change-Id: I58aec38b9fac6b7cbdcfe62e81e3b38ca3373a4c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2864370
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Simplify a lookup against two boolean variables that was implemented as
a nested set of ifs as a single match.
This also fixes a clippy warning about nested if inside else.
BUG=None
TEST=bin/clippy
Change-Id: Ia8e57a87dc5555ba505bcca67912eef978db0420
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2864366
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Replace an instance of Vec::new() followed by push to fix a new clippy
warning and simplify the code.
BUG=None
TEST=bin/clippy
Change-Id: Ie216df8ce5dcc12f5a2cceda8e322303804b451d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2864365
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Generalize the irq_enable() interface to accept a slice instead of a
Vec. This also fixes a few instances of the new clippy warning about
calling Vec::new() immediately followed by inserting items.
BUG=None
TEST=bin/clippy
Change-Id: If4c66999a245f340f54c96ccafc904c99bedf1ce
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2864364
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Many functions took a reference to PathBuf, but then just passed the
parameter to File::open(), so they can be changed to a reference to
Path instead to avoid a potential allocation.
https://rust-lang.github.io/rust-clippy/master/index.html#ptr_arg
BUG=None
TEST=bin/clippy
Change-Id: Ife5a52df2ba16da1ce1307efb2fe921cd8b4f956
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2862581
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
These parameters multiplied the number of type arguments to build_vm
unnecessarily and complicated the thread of execution in the programmers
head. Closures also complicate the borrow rules, making things much
harder to change.
This change uses the results of the closures (e.g. PCI devices, IRQ
chips) as parameters instead. The rest of this change follows naturally
from pulling on that thread until tests pass.
As a result of the removal of several type arguments, the code size was
reduced by ~100KiB on a 5MiB build.
BUG=b:185170486
TEST=./test_all
Change-Id: I6bcc5eb1b1f3031d4328bb4a81ddef618d04767b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2829136
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
A bugfix to minijail made the logic more strict so deduplicate the
mapping requests before giving them to libminijail.
BUG=b:2591867,chromium:1198756
TEST=CQ passes
Change-Id: Ide397e9aa82b493418d8ac4e51a73af649295424
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2851078
Tested-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Allen Webb <allenwebb@google.com>
- Removes duplicated code
- Assumes "u32" as the type of the flexible array
length field, which should be fine.
BUG=b:173630595
TEST=compile and run
Change-Id: Ia2d9f74b823e06d2f2f0b60cebb8a3b999a9cba0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2848283
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Avoid some easily-replaced non-inclusive words and remove them from the
unblocked_terms.txt list.
Remove a clippy lint with a name matching the list since all affected
warnings have already been removed.
Remove all terms that are already not present in the crosvm
repository from unblocked_terms.txt (including the commented lines).
BUG=b:178821708
TEST=../dev/contrib/search_blocked_words.sh unblocked_terms.txt
TEST=cargo test -p devices
TEST=cargo test -p disk
TEST=bin/clippy
Change-Id: I8261921380decc839f01adb9ad1d4d14d5a85114
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2847462
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This structure only embeds libvda::decode::Session, so we can directly
implement our traits on it. Doing so is actually more consistent with
the way the rest of the module is implemented.
BUG=None
TEST=cargo build
Change-Id: Ib03481ae91affca03cff21829e09d6d94731f78d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2845634
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The current design of having the VDA instance outside of the Decoder was
mandated by the use of lifetimes on libvda Sessions, which have been
removed from libvda. So it is now possible for the Decoder to own its
VDA instance.
This makes sense in itself since there is no reason for the VDA instance
to also be used by someone else, but is also required to add support for
non-libvda decoder backends.
BUG=b:169295147
TEST=Video plays correctly on hatch-arc-r.
Change-Id: I7cbafbb48373a25195de07e954846e1bd9f1cc0e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2839464
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The libvda API has been changes and both instances and sessions do not
use lifetimes anymore. Remove them from our code or it won't compile.
BUG=b:169295147
TEST=cargo build --features="video-decoder"
Cq-Depend: chromium:2838714
Change-Id: I7ba771abcdddfc4bc366dc38e37c0568ce5a9cb3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2845633
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
As new features are about to be added, it only makes sense to
improve error handling first.
Also improve/update naming of errors in other GPU-focused areas.
BUG=b:173630595
TEST=compile and run
Change-Id: If0d4f8b7d548c46f0a15b64699502e0fefeaae3e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2844350
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Replace the interface descriptors for unclaimed interfaces with
vendor-specific class codes so that the guest driver does not attempt to
bind to them.
BUG=b:180238956
BUG=chromium:1030778
TEST=Attach YubiKey, Circuit Playground Express to Crostini
Change-Id: Ia2826479c470e6f8a6dff21fe12e6c4bb5fd2efa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2811862
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Rearrange the control request type match to check the request and
recipient together in a tuple (along with direction, which will be
different for a Get Descriptor request, to be added in the next commit).
No functional change.
BUG=b:180238956
BUG=chromium:1030778
TEST=Share USB device with Crostini
Change-Id: I51badd8f8b067a5e19216a92257c2b75c2041663
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2811860
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This initializes the claimed_interfaces list at startup (before the
first Set Configuration request). It also makes it possible to catch
initialization errors earlier in the process of adding a device, before
it is added to the emulated USB hub.
BUG=b:180238956
BUG=chromium:1030778
TEST=Share USB device with Crostini
Change-Id: I6f27ec9b7ff6cda2ff23cadd77611f8ce1cfc89e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2811859
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When there is only one configuration listed in a device's descriptors,
assume that configuration is the active one without needing to send a
blocking control request to get the active configuration from the
device.
This moves the logic used in the USB host device code into usb_util, so
it will be used for all callers of get_active_configuration().
BUG=b:180238956
BUG=chromium:1030778
TEST=Share USB device with Crostini
Change-Id: I71a7d12a7edcd1fd0d063af58f63708b3dbda348
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2811858
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The mutex around the thread is locked-unlocked twice, the first time
just to check that something actually needs to be done, the second time
to check again and do it. The temporary release of the lock is to avoid
holding multiple locks while duplicating the fds and avoid the risk of
deadlock.
Change-Id: I455415dc32a31ae54025454f2709583e54a216b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2844354
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The syscall_defines crate is redundant with an up to date libc. This
change removes any dependency on syscall_defines. A new libc is required
to bring in some new syscall numbers like the ones for io_uring.
TEST=./test_all
BUG=None
Cq-Depend: chromium:2832000
Change-Id: I6df7fb992bacb5efd54cefca08836d52f4bfcd8c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2832001
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
This also fixes a self convention warning for sys_util::sock_ctl_msg and
removes a stray semicolon from ac97_bus_master.
BUG=None
TEST=cargo clippy && cargo test
Change-Id: I7fcf7577e09888836f7664d7127f94c9c24d3cfa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2840050
Tested-by: Allen Webb <allenwebb@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Commit-Queue: Allen Webb <allenwebb@google.com>
The recv thread was started immediately after the client object was created,
which caused minijail to abort refusing to fork a multithreaded process.
BUG=b/185811304
Change-Id: I5608e3b89eb4dfd944542d163e60b78937d37ba1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2837306
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
For vfio-platform we will have many platform IRQs per vfio-platform
device, so we need to pass the irq index to these functions in this
commit, rather than inferring the IRQ index from the IRQ type (intx
vs msi vs msix).
In other words, this commit eliminates some assumptions in the common
vfio code that we are working with vfio-pci devices when doing vfio
passthrough.
BUG=b:185504618
TEST=cros_workon_make
Change-Id: Iaa02c387fb8a679217d4cc9dabecf7fc61f9c9fb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2829293
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Micah Morton <mortonm@chromium.org>
In this CL, the decoder gets the buffer modifier via resource_bridge,
and then passes the value to the backend.
BUG=b:79682290
TEST=run media CTS and check the modifier is passed to GAVDA
Cq-Depend: chromium:2820734
Change-Id: I27b845251bf4a12efb74193945a6cb952c8f14af
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2821108
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Rust's libc considers android to be different than linux and provides
certain functions exclusively for target_os = "linux".
BUG=b:185155959
Change-Id: I664821fd678f0c911deb9312fe5fcfc9faf00053
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2822209
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Because the default value for mode is GpuMode::ModeVirglRenderer, make
the default value for use_vulkan false as well.
Set use_vulkan to true when mode is set to GpuMode::ModeGfxstream for
backward compatibility.
BUG=b:178104043
TEST=cargo build
Change-Id: Idf1417f04d23999cf5a03b0bf640973b69de93e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2823012
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Chia-I Wu <olv@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
Having a trait for interrupts used by queue and the devices allows for a
slightly different implementation to handle interrupting the guest when
using vhost-user.
Change devices to handle the resample event being optional as it is
handled on the VMM side with vhost_user.
Change-Id: I511d3db66a7986e7a2a8bce5f48285171dee3388
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2795284
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
In multi-process mode, we currently rely on dma-buf mmap() to
map GPU buffers into the guest. We usually have to fix the
Mesa driver, and maybe even the kernel to get to work. That's
"kind of" fine for ChromeOS, which owns the entire stack.
For their Virtual Graphics Interface (VGI) initiative, Android
upstream has requested multi-process mode to work in a
cross-platform, generic way. Using Vulkan is the only option
that meets the rigorous, uncompromising, strict, meticulous and
bone-crushing requirements of Android upstream.
This has possible two benefits:
1) We can enable multi-process mode on Nvidia or other
closed-source drivers, which is nice for Cuttlefish.
2) On open-source drivers, dma-buf memory is pinned to the
GTT (amdgpu), even when ideally it can be moved into faster
vram regions. This atleast gives the implementation the
chance to do the smarter and faster option.
We shouldn't run into any SELinux issues since the main crosvm
process is not sandboxed.
Incidentals:
* Changes vulkano_gralloc to consider integrated GPUs and dGPUs.
Metadata query is preferred done on the integrated GPU.
* Update vulkano_gralloc to match top of tree vulkano.
BUG=b:173630595
TEST=used Vulkano allocator and mapped memory into the guest
Change-Id: I78b069c7478d11b3201397894dcccd13bdc61f2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2792042
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Fds created via dup don't share file descriptor flags with the original
fd, which means that they don't have the FD_CLOEXEC flag set. Use
fcntl(F_DUPFD_CLOEXEC) so that this flag gets set for the duplicated fds
as well.
BUG=none
TEST=unit tests
Change-Id: Ib471cf40acac1eacf72969ba45247f50b349ed58
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2809687
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This CL addresses some minor issues with the existing interface:
1. from_descriptor is too generic for some platforms that require
special handling for file/File backed mappings.
2. Nearly all call sites pass either File or SharedMemory. Now
we just have from_ methods for those types to preserve type
information.
3. Other platforms require additional fields in MemoryMapping, so a
tuple struct no longer makes sense.
4. The mmap syscall error message was misleading as we use it for more
than just the mmap syscall.
BUG=None
TEST=builds
Change-Id: I74c41bad52bb81880a11231cd18f47e233548a24
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2815614
Reviewed-by: Udam Saini <udam@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
WaitContext and Reader/Writer are in the critical path for every device.
Use small vector optimization to avoid making unnecessary small heap
allocations.
The smallvec crate is maintained by the servo authors and only has an
optional dependency on serde.
BUG=none
TEST=pre-cq
Cq-Depend: chromium:2687076
Change-Id: Ic0c57ac949e263b70b76495e3c9121dd8c2e1177
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684062
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
With multiple regions potentially backing a single `GuestMemory`
instance, `AsRef` doesn't make sense any more. Switch the one user to
`shm_region` which returns the region for a given address.
The `AsRef` implementation was accidentally left in the change to allow
multiple regions in guest memory.
Change-Id: I1246de004315a44f1f9d58995d837f3fbecb5d6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2808745
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
This patch adds support for creating udmabufs via a guest provided
sg-list. Ideally, we'd create the udmabuf from a virtio-gpu guest
dedicated heap, but that needs further investigation.
In terms of the protocol, these following prototype items are added:
BLOB_CREATE_GUEST_HANDLE: "create an udmabuf" or an OS-specific
equivalent. This can be used with the guest dedicated heap or system
memory. Right now, only system memory is used.
We also want to associate the udmabuf with any host side metadata. For
example, SET_SCANOUT_BLOB doesn't passthrough the modifiers since
virtio-gpu KMS + modifiers is annoying. Simple solution: just ask the
host for the modifier. This could also enable different caching types
if the guest blob is mappable (for example, the MSM GPU driver currently
only supports WC mappings. We might also want cached mappings for
camera).
Incidentals:
* Add a placeholder for RESOURCE_SYNC
BUG=chromium:892806, b:173630595
TEST=create a bunch of udmabufs from the guest
Change-Id: I4686d9f48938f10e7c265750a931d7d2d2d9611b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786291
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
More recent Intel IO-APICs can support more than 24 interrupt
lines. This change enables variable size of IO-APIC lines for
user level IO-APIC emulation code (split-irqchip).
Reported version and supported IO-APIC registes matching ICH10
implementation of IO-APIC device.
BUG=b:181795297
TEST=boot and allocate irq from upper range.
Change-Id: I56480befb39c4c268266f04e4a93105402248772
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2733579
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>
Bug: 181664980
Test: Launch cuttlefish with crosvm, observe switches /dev/input
device with `getevent -lp`.
Test: cargo test
Change-Id: I209b93421bcfcc4ab26efc8981fcd2d680717d59
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2765762
Reviewed-by: Zach Reizner <zachr@chromium.org>
Auto-Submit: Daniel Norman <danielnorman@google.com>
Commit-Queue: Daniel Norman <danielnorman@google.com>
Tested-by: Daniel Norman <danielnorman@google.com>
Indicate that the code block with instructions for running bindgen is
not Rust code to avoid this warning:
warning: could not parse code block as Rust code
BUG=None
TEST=cargo doc --all-features
Change-Id: I38a9d49487dc1da8e41d3fca5dfa1b8bc8ae5e84
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2762064
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
To allow for porting to non POSIX platforms, we've brought the
libchromeos::sync module into cros_async (which was the only
consumer).
BUG=b:180978556
TEST=builds
Change-Id: I97256b1dc37124cebc693c035e63d2c5b29e94b1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757280
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
When the V4L2 output queue is streamoff, crosvm gets QueueClear
command. All the V4L2 output buffers are dropped, but VDA doesn't drop
output buffers at this point. We should only clear the enqueued
resource ids, and not clear the whole output resources.
BUG=b:181541291
TEST=android.media.cts.AdaptivePlaybackTest
TEST=com.google.android.exoplayer.gts.DashTest
Change-Id: I343b809e80d5bc56679b76baa5593aebb4558a74
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2756068
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
This change is to cleanup some dead_code warnings that appear if certain
features aren't enabled.
This also updates the Cargo.lock when changed due to zeroize being added
to libchromeos-rs.
TEST=cargo check --all-features
BUG=None
Change-Id: I5347b584a7426dc37f3933b1e907b23a71145749
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2753128
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
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 change is similar to http://crrev.com/c/2736520, which made the
path of the KVM device configurable. Similarly, most users will want
to keep the default paths of `/dev/vhost-vsock` and `/dev/vhost-net`.
In certain environments, namely Borg, those device nodes may be located
elsewhere.
BUG=None
TEST=./ci/builder --vm ./run_tests
Change-Id: I4bd7944d8f84fc0e7d255a3930c27f48a980e617
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2749235
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Set the SECBIT_NO_SETUID_FIXUP securebit so that we don't lose
capabilities when changing the thread uid/gid. This allows us to
simplify the create and mkdir functions so that all the checks we
currently carry out are only done once by the host kernel.
To ensure that the setuid and setgid bits still get dropped when a file
is modified by a process that doesn't hold CAP_FSETID, check for
WRITE_KILL_PRIV in the write flags and temporarily drop CAP_FSETID when
it is set.
BUG=none
TEST=Check that default posix acls, setgid bits, and file/directory
creation via membership of a supplementary group all work as
expected.
Change-Id: I420484e357a970e997cb3e968a433278e82d8ad4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684067
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Make the forked child processess easier to distinguish.
Also tweak the debug_label for virtio-pci devices so that more of the
name can fit into a limited-length thread name.
BUG=None
TEST=pstree
Change-Id: I74a8c1f5ab869e814bed4f2bd71c3de5179f7855
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2740526
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Crosvm pre-allocate mmio for device, but it doesn't enable memory/io
space in pci command config register, then OVMF doesn't use the pre-allocated
mmio and reallocate device mmio.
BUG=b:179053182
TEST='crosvm run -bios OVMF.fd' and check device info in efi shell
Change-Id: I7176e7f9716d829efff1ea023666eb705b525e5c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2741920
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
All virtio devices have virtio version 1.0 as base feature, but this revision
id isn't in pci configuration register, then OVMF won't start virtio 1.0
driver, and virtio device couldn't be used in OVMF.
BUG=b:179053182
TEST='crosvm run -bios OVMF.fd' and check virito blk device in EFI shell.
Change-Id: I8cbcd71b9b6ccef07b56853b7450b74e4dcbae1b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2741919
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
To track arc in VM in UMA and to separate it
from other linux VMs.
Changes:
- Add client_type options to Ac97Parameters.
- Add client_type option for the ac97 devices with CRAS backend.
BUG=b:177393225
TEST=Apply full patch set and start audio in ARCVM with
`cras_test_client --dump_a`
Cq-Depend: chromium:2744525
Change-Id: I27201aa65baed0ee59cf689dd7f22b5b91f00946
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2744968
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
While a host virtio device provides |num_queues| virtqueues, a guest virtio driver doesn't necessarily use all of them. For example, the virtio-blk driver uses only |nr_cpu_ids| virtqueues at most [1].
To avoid checking whether each queue is ready in each device implementation, we can filter them before starting device activation.
[1]:
https://patchwork.kernel.org/project/linux-block/cover/1553682995-5682-1-git-send-email-dongli.zhang@oracle.com/
BUG=b:179671351, b:181753022
TEST=CQ
Change-Id: I29d21d8d9db2d99aa9591ca55c18d06d2368797e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2732735
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Add #[repr(packed)] to struct virtio_blk_config to make its size same with the
the origianl C struct. The packed annotation will remove 4-byte padding at the
end of the struct and make the size of the struct smaller. (64 bytes -> 60 bytes)
Since it won't affect offsets of any fields, it shouldn't change any behavior
when the guest reads a config field. But, it can matter when the entire config
struct is passed via vhost-user protocol.
BUG=none
TEST=run a VM
Change-Id: I4dca9f1bdd93166192eca4d05d542ce851852aa7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2726059
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
After the userspace streamoff the input queue, the crosvm should not
return the previous frames. However, VDA might still return frames
before notifying reset is done. This CL drops the decoded frames after
calling VDA::Reset() until reset is completed.
BUG=b:181087034
TEST=android.media.cts.AdaptivePlaybackTest
Change-Id: Ieaa40ef27f1b37a262c80f9f30698c03ef16bdb9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2728584
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
When the video is flushed, V4L2DecodeComponent streamoff V4L2 output
and input queue. Then crosvm releases all output buffers and calls
VDA::Reset(). However, VaapiVDA implementation doesn't release output
buffer at Reset(). If Vaapi decodes the following frame before
V4L2DecodeComponent QBUF any output buffer, then crosvm will drop the
decoded frame.
This CL makes crosvm postpone sending the decoded frame if this
situation happens. Crosvm would sends the decoded frame when receiving
the buffer again.
BUG=b:181087034
TEST=emerge-hatch-arc-r crosvm
TEST=android.media.cts.AdaptivePlaybackTest
TEST=seek video many times and check no error occurs at the end of video
Change-Id: I0c8e59e2a206d6b2cd2009fd70380e7d5a366953
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2719245
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
Originally, process_cmd function can only return the response of the
procesesed cmd. However, we need to return the response of events for
some commands. This CL makes the process_cmd function could return
the responses of both command and event.
BUG=b:181087034
TEST=emerge-hatch-arc-r crosvm
Change-Id: Ie781795f8cee1c66e8462c602f876043b0dea9bc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2719244
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
Originally process_cmd() return VideoResult<VideoCmdResponseType>.
However, VideoCmdResponseType could return the error result by
Sync(CmdResponse::Error). VideoResult is not needed.
This CL change the returned type of process_cmd() to
VideoCmdResponseType to reduce code complexity.
BUG=b:181087034
TEST=emerge-hatch-arc-r crosvm
Change-Id: I1795a3eb09fe36076f5ad43fdd8d1eb9e21ffcd9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2731607
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
- Add an address space region for the protected KVM firmware.
- Query firmware size, mmap something that size and create a memslot.
BUG=b:163789172
TEST=cargo test
Change-Id: I054cf5d763c980d073c17bce70e85a781816b64d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2623942
Auto-Submit: Andrew Walbran <qwandor@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
In a long-running system, there is no reason to expect that a
significant number of freed pages are consecutive. However, batching is
relatively simple and can result in significant gains in a newly booted
system, so it's worth attempting.
BUG=None
TEST=arc.Boot.vm
Change-Id: Ia7dff4ab095d640a2a23ac4976bc277b09d9ea79
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2666412
Commit-Queue: David Stevens <stevensd@chromium.org>
Tested-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The max values for the multitouch slot ID and tracking/finger IDs were
set to zero previously, making it impossible to track multiple
fingers. This CL updates the max values to allow for 10 MT contact
points.
BUG=None
TEST=applied known working code from another branch.
Change-Id: Ic2e9919c2b83368eb1bc2085122c672fdafbdc84
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2708669
Reviewed-by: Tristan Muntsinger <muntsinger@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Noah Gold <nkgold@google.com>
When the file system implements zero message open support, the file
handle is meaningless and it needs to know the inode of the
file/directory on which the ioctl was called.
BUG=b:180565632
TEST=lsattr, chattr, both work when zero message open is enabled.
Android's FileBasedEncryptionPolicyTest[0] gets ENOTTY as an error
instead of EBADF
[0]: bfbc00c20d/tests/tests/security/native/encryption/FileBasedEncryptionPolicyTest.cpp
Change-Id: Ic55ee95df928d645874dd8a9c7dc579b708927fa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2706370
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: kokoro <noreply+kokoro@google.com>
Handle data offset for input bitstream buffers, as it is sometimes used
to skip headers at the start of buffers.
BUG=b:174531173
TEST=android.media.cts.MediaDrmClearkeyTest#testClearKeyPlaybackMpeg2ts
Change-Id: I6beee5cde24803ba90638c1dc130b75466f4847d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2692676
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
This is the original CL with one minor exception: we don't bind
mount the camera socket with the GPU device. That was the prior
behavior, and for some reason it really doesn't work with Mali +
SECCOMP[1]. It's not really important for the Wayland prototype,
so we'll let the camera team figure it out if and when they are
so inclined.
Bug: b:146066070
Bug: b:173630595
Bug: b:150239451
Bug: b:180126126
TEST=arc.Boot.vm
[1] audit(1613339319.226:43): auid=4294967295 uid=603 gid=603
ses=4294967295 subj=u:r:cros_camera_algo:s0 pid=17107
comm="cros_camera_alg" exe="/usr/bin/cros_camera_algo" sig=31
arch=40000028 syscall=54 compat=1 ip=0xe86a70b8 code=0x0
This reverts commit 51e1c4ad3e3a71a263501d2566d3b1ea59ba2070.
Change-Id: I74f49ece55656d7a9096900e3f19a528234b4224
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2695550
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Robert Tarasov <tutankhamen@chromium.org>
Enable the ZERO_MESSAGE_{OPEN,OPENDIR} features when the cache policy is
"always". This feature allows the kernel to skip the open message after
a successful lookup, reducing the amount of work that the server does.
This is implemented by changing the file descriptors stored in the
InodeData from O_PATH fds to O_RDONLY fds for files and directories.
Other types of directory entries (symlinks, special files, etc) still
use O_PATH fds.
If the kernel sends a write request for an fd opened in read-only mode
or a read request for an fd opened in write-only mode (can happen when
creating a new file), then we open a new fd in read-write mode before
performing the read/write. This only needs to happen the first time we
get a request that doesn't match the open flags.
This change should improve performance of opening and reading many small
files. It improves the blogbench read score by ~40% but reduces the
write score by ~25%. It also reduces the work done by the virtio-fs
server when loading roblox. The first load time is reduced by
~17% (3.04 seconds -> 2.52 seconds) and non-initial load times are
reduced by 50% (0.3 seconds -> 0.15 seconds).
BUG=none
TEST=vm.Virtiofs, vm.Blogbench.virtiofs, arc.PlayStore.vm, load roblox
inside arcvm
Change-Id: I042246a2fd9f7a0feeffc0f629073c594626392a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684066
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
This reverts commit a9c4b3a749.
Reason for revert: This made ARCVM fail to boot on kukui-arc-r. See http://b/180126126.
Original change's description:
> rutabaga_gfx: cross-domain: a new year's miracle in February
>
> The cross-domain context is specialized for cross domain
> allocation/resource sharing. It takes direct inspiration from
> the pioneering virtio_wl device and tries to incorporate
> similiar functionality into virtio_gpu.
>
> The goal here is just to introduce the building blocks so we
> can continue experimenting. In particular, this change:
>
> * hooked up the RutabagaChannels. This is typically a socket to
> Wayland or Mojo for the camera use case.
>
> * added CROSS_DOMAIN_CMD_INIT and CROSS_DOMAIN_CMD_GET_IMAGE_REQS
> to the cross-domain protocol. Further commands (such as
> CROSS_DOMAIN_SEND) will be needed, but that requires more
> Sommelier refactorings.
>
> * added a path to RutabagaGralloc to allocate via minigbm or shared
> memory.
>
> * Recieves responses via a shared ring buffer of type BLOB_MEM_GUEST.
> The synchronization protocol looks positively primitive compared to
> the revolutionary Address Space Graphics (ASG) algorithm [1], but
> it may be sufficient for the Wayland use case.
>
> [1] https://goto.google.com/address-space-graphics
>
> BUG=b:146066070, b:173630595, b:150239451
> TEST=launch virtual machine with 2D mode
> TEST=launch virtual machine with 3D mode
> TEST=run sommelier with "wl-dmabuf" and "wl-shm"
>
> Change-Id: I46784f17040494ce3a646bdbde516800aa64bd5d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626488
> Tested-by: kokoro <noreply+kokoro@google.com>
> Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
> Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
> Reviewed-by: Zach Reizner <zachr@chromium.org>
Bug: b:146066070
Bug: b:173630595
Bug: b:150239451
Bug: b:180126126
Change-Id: Ie33442fdcedcf43b6a24d25198fa2d88b5b96919
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2695056
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Hiroki Sato <hirokisato@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Hiroki Sato <hirokisato@chromium.org>
Commit-Queue: Hiroki Sato <hirokisato@chromium.org>
Destroying a stream while there are outstanding async commands results
in the responses for those commands having no corresponding tracked
descriptor. Instead of trying to handle this case specifically, make
untracked async responses non-fatal errors, instead of shutting down the
decoder device completely.
BUG=b:177697115
TEST=android.security.cts.StagefrightTest
Change-Id: I142ec9814fd69ddb79ef16140b7b06cd0c9f0123
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2690728
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
The newly added async primitives allow for increasing the separation of
the various tasks performed by balloon. Breaking each task in to an
asynchronous function.
BUG=chromium:901139
TEST=Boot crosvm, run 'crosvm balloon' to set the balloon size, check
'vmstat' inside the VM to verify the free memory is affected by the
balloon growing and shrinking.
run crosvm balloon_stats command and ensure that stats are reported
correctly.
Change-Id: I0ae2be5eb8e4be65b2eb74de90888357af6ecfd4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1993163
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The cross-domain context is specialized for cross domain
allocation/resource sharing. It takes direct inspiration from
the pioneering virtio_wl device and tries to incorporate
similiar functionality into virtio_gpu.
The goal here is just to introduce the building blocks so we
can continue experimenting. In particular, this change:
* hooked up the RutabagaChannels. This is typically a socket to
Wayland or Mojo for the camera use case.
* added CROSS_DOMAIN_CMD_INIT and CROSS_DOMAIN_CMD_GET_IMAGE_REQS
to the cross-domain protocol. Further commands (such as
CROSS_DOMAIN_SEND) will be needed, but that requires more
Sommelier refactorings.
* added a path to RutabagaGralloc to allocate via minigbm or shared
memory.
* Recieves responses via a shared ring buffer of type BLOB_MEM_GUEST.
The synchronization protocol looks positively primitive compared to
the revolutionary Address Space Graphics (ASG) algorithm [1], but
it may be sufficient for the Wayland use case.
[1] https://goto.google.com/address-space-graphics
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=run sommelier with "wl-dmabuf" and "wl-shm"
Change-Id: I46784f17040494ce3a646bdbde516800aa64bd5d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626488
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This was based on an unmerged set of kernel patches that have now been
dropped from the chrome os kernel as well. Remove them here.
BUG=none
TEST=cargo test
Change-Id: Id307bb0b51879033ea82c2d360a57752728fbf3e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2684065
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Allow the caller of config_register_write to determine whether a given
write to PCI configuration space has enabled or disabled the memory or
I/O bits in the command register. This will be used as a signal to
insert or remove a PCI device to/from the corresponding bus.
BUG=b:174705596
TEST=cargo test -p devices
TEST=Manual test with full PCI BAR remapping patch set
Change-Id: I7a3484bd5143d25756c6fdc9f3a8f684db7db8cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2388964
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This adds support for battery charge, voltage, battery charge counter
in power_monitor and populates these fields from powerd data.
BUG=b:162479956
TEST=Compare voltage_now, charge_full, charge_now/charge_counter,
current_now fields in sysfs on host and in ARCVM
TEST=CTS tests android.cts.statsd.atom.HostAtomTests#testBatteryVoltage,
android.cts.statsd.atom.HostAtomTests#testFullBatteryCapacity
and android.cts.statsd.atom.HostAtomTests#testRemainingBatteryCapacity
pass in ARCVM
Change-Id: I3f93f499fa7d00cc5a0a2b69e7cfbcd233a2983a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2681212
Tested-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alex Lau <alexlau@chromium.org>
Use resources allocator to assign or reserve PCI device address.
For pass-through devices it will enable 1:1 mapping to the host BDF.
Transition to address_allocator for pci address and irq allocations.
BUG=None
TEST=build_test && tast run vm.*
Change-Id: I854da9645a305b7b24acb3dd6d851c3486ed23f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2210848
Tested-by: Tomasz Jeznach <tjeznach@chromium.org>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Adds the crosvm-side infrastructure to build and test
in kokoro.
There is a build script for testing on x86, aarch64
and a separte script for analysis (clippy, fmt).
These will run in parallel on Kokoro. To test the
scripts locally, a simulate script is provided.
Runtime on my workstation:
- aarch64: 10m
- x86: 2:30m
- analysis: 1:40m
BUG=b:177951955
TEST=./ci/kokoro/simulate_all
Change-Id: I2f666ec768e6c3391a258dc7f0cbd999ad9b2fb1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2654413
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
When building without the "audio" feature, an import of virtio::snd in
pci_device failed to compile; wrap it in a feature check to fix this.
This fixes the crosvm fuzzer build.
BUG=chromium:1174254
TEST=cargo build --no-default-features
TEST=build crosvm with amd64-generic asan profile
Change-Id: Iecd549c313d6210ee90e9e405c02a9e7581e1141
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2674260
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
rutabaga_gralloc is a cross-platform, Rust-based buffer
manager.
The rationale for this change is:
1) For the {cross-domain, wayland} context type, we need to
have a good story for the crucial "wl-dmabuf" feature. As
minigbm has been thoroughly tested on ChromeOS and currently
powers the "wl-dmabuf" feature, it only makes sense for us to
have a path to minigbm for the cross-domain prototype. This
will be used by Sommelier.
2) While minigbm allocation works well on Chromebooks, it is
not sufficient for cross-platform purposes. For their Virtual
Graphics Interface (VGI) initiative, Android graphics
virtualization experts have expressed their desire for a Vulkan
based allocator. This will to go alongside cros_gralloc in
minigbm, which is considered by many to be the ""world's
premiere gralloc implementation".
3) Android graphics virtualization experts have expressed their
desire for vkMapMemory(..) to be used when crosvm is in
multi-process mode. Currently, only dma-buf mmap() is supported
for zero-copy blobs in multi-process mode. dma-buf mmap() is not
guaranteed to work on Nvidia (a "must have" for Cuttlefish) or
any other driver for that matter (we *make* it work for ChromeOS).
Possibly only solution: vkMapMemory ;-)
With these goals in mind, here's a summary of the revelant changes:
* Renamed the {gpu_allocator.rs, GpuMemoryAllocator trait} to be
{gralloc.rs, Gralloc trait}.
* Moved all GPU allocation out of the resources crate and into
the rutabaga_gfx crate. This will allow the resources crate to
be focused on managing resources for virtual machines.
* Moved the gpu_buffer crate into the gralloc module in the
rutabaga_gfx crate. The same functionality is now under
"minigbm.rs", "minigbm_bindings.rs" and "rendernode.rs"
* Added an optional dependency on vulkano.rs. vulkano.rs is a safe
Rust wrapper around the Vulkan api [a]. It's emphasis on type
safety makes a good fit for crosvm, though there are other high
quality crates out there (gfx-rs, ash.rs). Though development
has slowed down, it should satisfy goals (2) and (3) quite easily.
* Added a system_gralloc implementation based on memfd. This can be
used when minigbm or Vulkano features are not used, to replicate the
highly useful "wl-shm" feature in Sommelier. Astute observers will
note this can also enable seamless Wayland windowing without GPU
features for Android too. Some minor changes to the base crate were
needed.
* Cut down on the amount of DrmFormats to the subset needed by
Sommelier and cros_gralloc.
* Moved checked arithmetic into it's own file.
* Internally renamed to "wl-dmabuf" feature to be the "minigbm"
feature. This is because "wl-dmabuf" has a dependency on minigbm.
* Small rutabaga_gfx cleanups
[a] https://github.com/vulkano-rs/vulkano/blob/master/DESIGN.md
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=run sommelier with "wl-dmabuf" and "wl-shm"
Change-Id: I693a39cef64cd98e56d843d3c60caa7983d4d6e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626487
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Offset right now means the offset from base address that the
device was accessed at. And address is the absolute address
of the device's access in its address space. The port 0x61 and
0x64 is the absolute port number.
BUG=None
TEST=boot VM and run reboot command
Change-Id: I51ee90e51b559254cf76f2bec4d174294961fe1c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2648858
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Alistair Delva <adelva@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Alistair Delva <adelva@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
The arcvm guest has been observed to fail early in boot with a low
probability; the root cause seems to be a missing interrupt from the
virtio-block device causing the guest to wait forever for a notification
that does not happen.
In testing, it seems that ignoring the VIRTQ_AVAIL_F_NO_INTERRUPT flag
set by the guest avoids the issue; possibly there is a race in the
publishing of used descriptors versus the checking of this flag, but I
was not able to find a definitive solution.
Ignoring the flag means that we may occasionally trigger an interrupt
when the guest has indicated that one is not necessary; this is, at
worst, a slight performance degradation, not a correctness issue, since
the guest kernel will ignore spurious interrupts.
BUG=b:172975852
TEST=Restart arcvm in a loop without failures 1000+ iterations
Change-Id: I4c91ccc5dadc03dde43008ff20fae1c4592e19da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2648009
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
These will eventually be used when the virtio-snd device is
implemented as well as by the VioS audio backend.
BUG=b/174713663
Change-Id: Id9fe1527a128df0059805076c01e20ddb1ad2b72
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574812
Auto-Submit: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
There are a lot of changes in this one but these are the high-level
points:
* Both executors now support non-fd futures and it's now possible to
start a poll operation on one thread and then await the result inside
a UringExecutor on another thread. The reverse doesn't work yet but
will once we make UringContext sync.
* A few layers of indirection have been removed so hopefully both the
implementation and the interface are simpler.
* The thread local magic is gone in favor of directly calling methods on
an executor. Executor handles can be cheaply cloned to make this
easier.
* Heap allocations are limited to the spawn and spawn_local methods so
it's possible to completely avoid heap allocations if callers only use
the run_until method.
* The IoSource, Executor, FutureList traits are gone.
BUG=none
TEST=unit tests
Cq-Depend: chromium:2629068
Change-Id: I86053007929c36da66f3b2499cdefce0b5e9a180
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2571401
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The encoder should be able to start encoding when receiving 1 input
buffer. This CL changes the minimum input buffer from 2 to 1.
BUG=b:175745193
TEST=android.mediav2.cts.EncoderProfileLevelTest
Change-Id: I97060d0304cf41369467dc62d12bbae7e54b6b22
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2602299
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
The decoder should be able to start decoding when receiving 1 input
buffer. This CL changes the minimum input buffer from 2 to 1.
BUG=b:176266656
TEST=android.media.cts.DecoderTest#testEOSBehaviorVP8
Change-Id: I2b055b145993d35c00a07bc7081db84117e36423
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2602297
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
It's possible to compile the gpu device without virgl_renderer.
In fact, in many instances, this may be required.
This builds the gpu device default, but only with --gpu do I see
/dev/dri/renderN128, so this should be safe.
BUG=b:173630595
TEST=compile and run
Cq-Depend: chromium:2592111
Change-Id: I5fbf2de8a2f818a9ca2e5ac4a1a02c7797cff927
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2592089
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Support virtio-fs's DAX (direct memory access) operation which allows the guest
to directly access file pages.
Specifically, FUSE_SETUP_MAPPING and FUSE_REMOVE_MAPPING operations are
supported.
This option can be used by specifing `dax` option when mount a file system in
the guest.
The DAX optoin improved file I/O performance in most cases.
In Fio tests, both of read and write score were improved by 1.3-14x depending on
test cases.
In Blogbench tests, which create many small files, DAX improved the write score
by 1.5x while the read score was reduced to ~25% (20391 -> 4593).
Here is an excerpt of results:
Fio
* seq_read: 10.2x (143528 -> 1464911)
* seq_write: 3.3x (61253 -> 896791)
* rand_read: 11.6x (138753 -> 1612739)
* rand_write: 14.6x (61253 -> 896791)
* surfing_read: 1.3x (98473 -> 127907)
* surfing_write: 1.3x (83309 -> 108089)
Blogbench
* read: 0.23x (20391 -> 4593)
* write: 1.50x (248 -> 373)
BUG=b:147341783
TEST=Run vm.{Blogbench, Fio} with CL:2291856
Change-Id: I4a47c601412ed32d926de6304337e1594252d258
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2108315
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
clippy 1.48.0 has a bug in string parsing in doc comments.
https://github.com/rust-lang/rust-clippy/issues/6022
To avoid this issue, update to use double-quotation instead of single-quotation
inside a code block in a doc comment.
Also, this fixes wrong examples of commands there at the same time.
BUG=none
TEST=bin/clippy
Change-Id: I90e5699f6d4e839304f9d4e05e5c7b21467744cd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2592001
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This CL adds support for VIRTIO_VIDEO_CONTROL_FORCE_KEYFRAME to the
crosvm encoder.
BUG=b:161498590,b:174444769
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Ibe0c7d2aa7b41c6a0168a7aa312d6996cc22ef23
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2567308
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Currently only H.264 level 1 is reported to the virto encoder when the
supported H.264 levels are queried. This CL expands the list to contain
all levels up to 5.1 which are supported by most devices, as the VEA
interface currently has no way to query the maximum supported H.264
level.
BUG=b:174967472
TEST=android.media.cts.MediaRecorderTest#testProfileAvcBaselineLevel1
Change-Id: I960f9176fa00180da6f71bcdad558da06e8247c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574583
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Currently only the framerate requested on the CAPTURE queue is used to
configure the Chrome encoder's framerate. But according to the V4L2
standard setting the framerate on the OUTPUT queue should also set the
framerate on the CAPTURE queue to the same value.
BUG=b:173668157
TEST=android.media.cts.MediaRecorderTest#testProfileAvcBaselineLevel1
Change-Id: I0753d10d73d52ce4f17fd9bc230d4fa2f06a1b30
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2570833
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
As part of moving from RawFd to RawDescriptor and related types
(https://crrev.com/c/2462330), the USB attach code was modified to
accept a MaybeOwnedDescriptor instead of a MaybeOwnedFd. Since
MaybeOwnedDescriptor::Owned contains a SafeDescriptor instead of a File,
and the usb_util Device::new() constructor requires a File, a conversion
is required. However, the patch mentioned above used as_raw_descriptor
and File::from_raw_descriptor to do this conversion, but this leaves
both the SafeDescriptor and the newly-created File assuming ownership of
the USB fd. When the SafeDescriptor went out of scope, the fd would be
closed, causing the fd in the File to be invalid (meaning the USB device
does not function at all).
This would show up in the crosvm logs like this:
[devices/src/usb/host_backend/utils.rs:61] fail to submit transfer IoctlFailed(2151175434, Error(25))
[devices/src/usb/xhci/xhci_transfer.rs:399] backend is already disconnected
To fix this, use into_raw_descriptor rather than as_raw_descriptor to
transfer ownership out of the SafeDescriptor without closing the fd.
BUG=b:174289633
BUG=chromium:1151144
TEST=Attach USB serial device to Crostini and verify /dev/ttyUSB0 exists
Change-Id: Ia1c5f94f69ca31ab211ab9f63f23141b4e774ef4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2579884
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Michael Hoyle <mikehoyle@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is a chromeos extension to fuse to support the O_TMPFILE flag.
BUG=b:160932094
TEST=Open a file with O_TMPFILE on a virtio-fs mount
Change-Id: I21a6390e919d5949fbd12bb304b20374b9b9172a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2520561
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
rutabaga_gfx is a cross platform, Rust-based, Wayland and
Vulkan-centric Virtual Graphics Interface (VGI).
Apologies for the mega-change, but it was hard to do this piece
by piece.
The rationale for this change is:
1) Android graphics virtualization experts have been proposing
for a VGI for many months (years?). Their goal is to boot
Android anywhere, everywhere.
2) For the {wayland, cross-domain} context type prototype,
it's desirable to create a {wayland, camera} connection at the
appropriate time. Details can be found in the code, though the
RutabagaChannels have yet to be hooked up.
There's a high chance neither effort will work. As such,
rutabaga is just a prototype.
However, even (1) and (2) don't end up working, this
refactor/cleanup by itself makes a ton of sense.
Here's a summary of revelant changes:
* Removed auto-generated {p_defines, p_format, virgl_protocol}.
These files were added for tests when bringing up crosvm-gpu,
and AFAICT these tests are not run. There's actually now a
commit queue for virglrenderer changes and container boot tests
that provides excellent coverage.
* Removed command_buffer.rs. Used only for the previously
mentioned tests. It's quite nice, but couldn't determine the right
place to put it. Maybe data_model? But removed it in the interim.
* Removed {write_from_guest_memory, read_to_volatile}. The same
basic functionality has been moved into {transfer_write,
transfer_read} in Rutabaga.
* Removed VirtioResource, Virtio3DResource, Virtio2DResource,
and VirtioGfxStreamResource in favor of VirtioGpuResource and
RutabagaResource. This leads to less duplication and clearer
separation between external library functions and VMM functions.
* Moved display and hypervisor memory management functions to
virtio_gpu.rs. This is because external components do not interface
with this functionality, and there was a lot of duplication (for example
map/unmap blob).
* Added context management between gfxstream and virglrenderer.
* Added separate gfxstream and virglrenderer flags.
* Clearer naming.
* Added simple implementations for context init and multiple timelines.
These changes have no effect since all Google kernels don't pass the
revelant flags, but are useful for theoretical {wayland, cross-domain}
prototype.
* Unify RESOURCE_CREATE_3D and RESOURCE_CREATE_2D handling.
* Better error handling.
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=boot ARCVM
Change-Id: I240b0c134a3b562cbc65981837a41f6db7767c92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2522452
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This CL
- simplifies ac97_bus_master audio thread spawn logic
- makes data ownership more clear for future maintenance
- saves several redundant lock calls
High level design:
ac97_bus_master <=> one AudioThreadInfo for each Ac97Function
<=> start / stop an AudioWorker
Changes in this CL:
- Add AudioWorker which contains the data, logic inside spawn::thread()
and some controls which own by AudioThreadInfo
- Remove `fn audio_thread`.
- Make AudioThreadInfo an audio thread control interface for each
Ac97Function
- `start` consumes an worker and spawn a running thread
- `stop` stops the thread and destroy the worker
- Add is_running support
- Combine several regs.lock() calls to save mutex lock time.
- Add create_audio_worker to create AudioWorker
BUG=b:173364323
TEST=Build and test audio in VMs
Change-Id: Iac8090fac12ac91f50b3e601efb918d79ba089af
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2550480
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Fletcher Woodruff <fletcherw@chromium.org>
Needed by arcvm. Also fix some style issues with the previous ioctl
definitions.
BUG=b:136127632
TEST=Call this ioctl from inside a VM and see that it is passed through
to the host.
Change-Id: Icdeff9e2c5b15237ed49e6814b8147258a50ccab
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2560286
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
These don't work without a kernel change that we never merged. Arcvm
doesn't need these anymore so just drop them.
BUG=b:136127632
TEST=vm.Virtiofs
Change-Id: I427dee41720b0db1d14f4d03c95ff678ec3fd347
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2573709
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
These are causing the clippy pre-upload hook to fail for me.
BUG=none
TEST=bin/clippy
Change-Id: Ifa5b6b008ca1e930ba203034234ce3da56830b11
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574584
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Fixes crosvm's failure to forward the "use_external_blob"
state flag to the host renderer (virglrenderer).
BUG=b:174794821
TEST=Start a crostini VM and run `DISPLAY=:0 glxgears`, verify graphical
output.
Change-Id: I1ef616079664224e7741cea00b9125c5061ea69d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574669
Tested-by: Ryan Neph <ryanneph@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
The V4L2 standard allows specifying a stride by using the
v4l2_pix_format.bytesperline field when configuring the input format.
This CL makes changes to properly use the stride requested by the
virtio encode device.
BUG=b:173083834,b:173666696
TEST=android.video.cts.VideoEncoderDecoderTest.testAvcOther0Perf0720x0480
Change-Id: Id7d8bb11ef02ee79c70225202471b9a6d21963c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2567309
Tested-by: David Staessens <dstaessens@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This CL makes changes so the VIRTIO_VIDEO_BUFFER_FLAG_IFRAME flag is
set and propagated back to the virtio encoder whenever the Chrome
encoder creates a keyframe.
BUG=b:173077927
TEST=tast run DUT arc.PowerCameraRecordingPerf.vm
Change-Id: I4029f3d7b745937e7960abba896c458182cf942e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2567307
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
This CL makes changes to use the output buffer size requested by the
encoder client. Typically this output buffer size will be overwritten
with what the underlying encoder requests in RequireInputBuffers, but
for correctness we initially store the requested buffer size. Changes
are also made to not set a resolution on the output parameters, as this
should be ignored according to the V4L2 standard.
BUG=b:162804477
TEST=tast run DUT arc.VideoEncodeAccel.h264_1080p_i420_vm
Change-Id: Id0c530271930eebd90e4f7ba00a186ea567ac10c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2519346
Tested-by: David Staessens <dstaessens@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This change adds support for exporting virtio_gpu fences into
virtio_wl.
Without support for sending fences over virtio_wl, ARCVM must wait in
the guest for fences to be signaled before sending the corresponding
buffers to the host compositor. Under normal composition, it is
relatively rare for fences to be unsignaled when they need to be sent
over virtio_wl, although it does still happen at the far tail end. If
ARCVM falls back to client composition, without this change ARCVM needs
to wait on average 5-15ms (depending on how heavyweight the app's
rendering is) for fences to be signaled.
Support for sending fences over virtio_wl allows this extra latency to
be hidden.
BUG=b:136129939
TEST=Run YouTube+Play Store+graphics benchmarks simultaneously
in ARCVM, with and without client composition.
Change-Id: Ic7f57069c4171104c497aee6721c5c93dc6bafa4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2363512
Tested-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This CL wires up the powerd D-Bus PowerMonitor implementation to GoldfishBattery.
BUG=b:137890633
TEST=observe updated power data in ARCVM's /sys/class/power_supply after crrev.com/c/2550102
Change-Id: I38c613f13d3f7601435532213c7733558cb5f83f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2560276
Commit-Queue: Alex Lau <alexlau@chromium.org>
Tested-by: Alex Lau <alexlau@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Allow the user to specify a serial number for each virtio block device
using the new id= parameter:
crosvm run --disk disk.img,id=SERIALNO ...
These serial numbers show up in sysfs for each block device, which
allows them to be uniquely identified regardless of the number or order
of block devices added on the crosvm command line. This can be used to
find a specific device by serial number for mounting at boot time.
BUG=b:157687637
BUG=chromium:775781
TEST=crosvm run -r vm_rootfs.img,id=root -p init=/bin/bash vm_kernel
TEST=cat /sys/block/vda/serial # see serial is set to "root"
TEST=cargo test -p devices
Change-Id: I108cdc47c367fb038d6acd55da60f9e1aae59e68
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2225559
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
A prior CL (@81d5adbad7) removed VIRTIO_F_VERSION_1 from the features on
virtio-rng, which causes Linux to skip and not utilize the RNG device.
This CL pipes protected-vm down to virtio-rng & restores the feature.
BUG=none
TEST=cuttlefish launch_cvd
Change-Id: I32d064ec1ac31e0fa622f14ea0f48988d8d6fa49
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2556080
Tested-by: Alistair Delva <adelva@google.com>
Auto-Submit: Alistair Delva <adelva@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
See crbug.com/1151517 for details on the failure.
See b/173833661 for a longer term fix.
BUG=b:173833661
TEST=None
Change-Id: I82499b72e39ab524584807dcc35c3d0be7ab1bff
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2553215
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Allow devices to be added to a Bus without a mutex. If a device
implements BusDeviceSync and is inserted into the Bus via the new
insert_sync function, the Bus will not lock the device before write and
read operations. This feature will allow IrqChip implementations to use
the mmio bus for APIC mmio, and allow each vcpu to write to their
respective APICs simultaneously.
This also changes the BusDevice trait so read and write functions take a
new BusAccessInfo struct. The BusAccessInfo conveys the full address of
the read/write operation, the offset of the address relative to the
device start address, and an id that in practice will hold the vcpu id
for the vcpu thread perforing the read/write.
As a result, inserts into the Bus are no longer distinguished between
full_addr and non full_addr inserts. Instead, each device's BusDevice
implementation must decide whether they use the absolute read/write
address or the relative read/write offset.
BUG=chromium:1077058
TEST=ran build_test
TEST=ran simple debian image
Change-Id: I9125aaa69869c1004b6c6a099b50f5c58038d4ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2514662
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Add methods to the IrqChip trait to block in userspace on halted vcpus.
Add IrqChip::check_capability, used for cpuid setup.
Move interrupt injection logic from linux.rs to a new
IrqChip::inject_interrupts method, which replaces interrupt_requested
and get_external_interrupt.
These changes are to support setup, run loop, and injection in the
userspace irqchip.
BUG=chromium:1077058
TEST=boots with KVM kernel irqchip, KVM split irqchip
Change-Id: I8f46b5edf36acc485b5f76e7aed3e71c3b984c0e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2419674
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This test exercises the jailing and communication with the forked
process.
The test must be run single-threaded for the
fork to be successful.
BUG=b:171750410
TEST=This is the test
Change-Id: I879dfa46a2d39ee8115ca6b81faf63c930aab3cb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2503480
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Auto-Submit: Dennis Kempin <denniskempin@google.com>
The write call would write in big endian, but the device should
be using native endian.
BUG=b:171750410
TEST=This bug was caught by the accompanying unit test.
Change-Id: I65aa4c89857766e5ef3280bde90e6ba3a33d1ebd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2515059
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Drain is cancelled by clearing either of the stream's queues. To work
around a limitation in the VDA api, the output queue is cleared
synchronously without going through VDA. Because of this, a drain
cancellation response from VDA might fail to find the drain's
AsyncCmdTag.
BUG=b:170184723
TEST=android.mediastress.cts.MediaRecorderStressTest#testStressRecordVideoAndPlayback
Change-Id: I1d54c9c4acfa7578addb947e1196313010a8431d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2535964
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
The S5 capability allows the VM to be powered off when user execute
'poweroff' command. This is done by trigger the exit event through
the ACPI PM1 control so that crosvm can shutdown the VM in the end.
BUG=None
TEST=boot a VM and then run 'poweroff' command from VM's shell. The
VM can exit.
Change-Id: Iaad5615fd72550568362090c3b876202055cc25a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2534098
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Wrap the code to access various parts of the virtio queue in-memory data
structures into helper functions to clarify the logic of the top-level
Queue functions. Previously, the memory address calculations and guest
memory read/write invocations were mixed together with queue "business
logic" in a way that made it hard to follow and led to duplicated code.
BUG=None
TEST=Boot crostini on eve
TEST=cargo test -p devices
Change-Id: I6e79b9909bde377cd078c75925c62de0234bb21b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2527815
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This CL transitions most structs to RawDescriptor and the
associated traits if possible.
BUG=b:162363783
TEST=./build_test
Change-Id: Iabae6ac212787836d77de2b9ffb5d451421ab0dd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2530911
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Michael Hoyle <mikehoyle@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
Add a new command "battery" which is used to modify the virtual
battery/ac status.
When there is goldfish battery device model created, the command
is able to sent to the goldfish battery monitoring thread. If no,
the command won't be sent.
The supported commands are:
1. crosvm battery goldfish status <status string> crosvm.sock
2. crosvm battery goldfish health <health string> crosvm.sock
3. crosvm battery goldfish present <number> crosvm.sock
4. crosvm battery goldfish capacity <number> crosvm.sock
5. crosvm battery goldfish aconline <number> crosvm.sock
"goldfish" is the battery identifier to specify which virtual battery
is going to be modified by this command in case there are multiple
virtual batteries in the guest in future. Right now only one goldfish
battery is supported.
BUG=chromium:1050432
BUG=b:137890633
TEST=create VM with parameter "--battery" or "--battery=type=goldfish"
and boot linux guest with goldfish_battery driver enabled. From host
side, execute command "#crosvm battery goldfish status discharging
crosvm.sock" can make the guest receive an interrupt, and the status
sysfs is changed to "Discharging". Also tested the other commands
as well.
TEST=modified values are visible in ARCVM and interrupts are triggered
Change-Id: I82177811a6f2b1960f7895522760ff3b8143163f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2119574
Tested-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alex Lau <alexlau@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The goldfish battery irq will be used to notify the guest driver that
battery/ac status changed. And the status changing will be done through
external crosvm commands. So the irq injection needs to be done in a
seperate thread which can receive these commands.
BUG=chromium:1050432
BUG=b:137890633
TEST=create VM with parameter "--battery" or "--battery=type=goldfish"
and boot linux guest with goldfish_battery driver enabled. The sysfs
created by the goldfish_battery driver have no issue observed.
TEST=goldfish_battery driver is loaded on ARCVM and interrupts are enabled
Change-Id: Icc902dd8c00bdcf6cb271b20d928a4081533dde6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2119573
Commit-Queue: Alex Lau <alexlau@chromium.org>
Tested-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Create goldfish battery device model for guest. Provide the
minimal properties and basic accessing for the golfish_battery
driver in the guest.
BUG=chromium:1050432
BUG=b:137890633
TEST=create VM with parameter "--battery" or "--battery=type=
goldfish" and boot linux guest with goldfish_battery driver
enabled. The goldfish_battery driver is loaded successfully.
The /sys/class/power_supply/battery and
/sys/class/power_supply/ac are created successfully.
TEST=cargo test -p crosvm
TEST=goldfish_battery driver is loaded on ARCVM after crrev.com/c/2519336
Change-Id: Iaafa09e3d7e5664d3db8b7df5295f077ec3f6da9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2119572
Commit-Queue: Alex Lau <alexlau@chromium.org>
Tested-by: Alex Lau <alexlau@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Instead of creating IoSourceExt from AsRawFd implementers, we've
switched to creating from a marker trait `IntoAsync`. This lets us use
other types like RawDescriptor easily with this crate. By using the
marker, we also provide some type safety by requiring consumers of
IoSourceExt to declare that their type is expected to work with async
operations. This way we can provide stronger guarantees that an async
IO trait object will behave in a reasonable way.
This CL also purges the cros_async -> base and io_uring -> base
references, and provides the base types needed to add new async
primitives to base.
BUG=none
TEST=builds
Change-Id: I0b0ce6ca7938b22ae8e8fb4e604439f0292678f2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2504481
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This CL fixes the wrong value being used when configuring a bitrate
using the V4L2_CID_MPEG_VIDEO_BITRATE control. Rather than using the
requested value, the original value was wrongly being used.
BUG=b:162804477
TEST=tast run DUT arc.VideoEncodeAccel.h264_1080p_i420_vm
Change-Id: I1381277c324eff035643b5f65c1e03832085e3f0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2522772
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Along with this rename comes updating all usages to the
appropriate RawDescriptor traits. As per usual it touches
many files, but makes no significant changes.
The only remaining instance of "keep_fds" is to call out to
3p lib adhd.
BUG=b:162363783
TEST=./build_test
Change-Id: I6d292cc6404a9f84ffa5bf1320b6545a28842afa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2488071
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
Tested-by: Michael Hoyle <mikehoyle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Without this, non-root X fails with
[ 7.544] (EE) modeset(0): drmSetMaster failed: Permission denied
because of the fallback
[ 7.367] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_31
[ 7.368] (II) xfree86: Adding drm device (/dev/dri/card0)
[ 7.368] (II) Platform probe for /sys/devices/pci0000:00/0000:00:06.0/virtio5/drm/card0
[ 7.368] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 10 paused 0
[ 7.369] (II) no primary bus or device found
[ 7.369] falling back to /sys/devices/pci0000:00/0000:00:06.0/virtio5/drm/card0
BUG=None
TEST=Arch Linux guest
Change-Id: I4921fbd22b77d43d190b7adeb0399fc77fcec908
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2518656
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
A decoder session is always associated to a given context ; therefore
our session map ends up having the same keys as the context map, with
the only difference that sessions are created a bit later.
Move the DecoderSession into the Context struct so we don't need to do
this double-lookup and to maintain consistency between the two maps. Since
the context can lack an associated session until the first output buffer
is queued, put the session behind an Option<>.
BUG=b:161774071
TEST=Youtube video playback works on kukui-arc-r.
TEST=Youtube video playback works on hatch-arc-r.
Change-Id: I0511e51d422700a161457bb796ced3f2ef4732e5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2484064
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Clippy is not happy because this method uses too many arguments. Since
we just happened to introduce a Rect type, use it to reduce them to an
acceptable number.
BUG=b:161774071
TEST=Youtube video playback works on kukui-arc-r.
TEST=Youtube video playback works on hatch-arc-r.
Change-Id: I88fd0af5be75e3ddf3d3e2c03593aa492a18830e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2484063
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Introduce our own event type to avoid using the libvda one in the
DecoderDevice interface. The current type is a 1:1 mapping from the
libvda event type, but we may simplify it in the future.
BUG=b:169295147
BUG=b:161774071
TEST=Youtube video playback works on kukui-arc-r.
TEST=Youtube video playback works on hatch-arc-r.
Change-Id: Ic0fa1276ffe33c510f8a36ff26a69ece4e271974
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2477407
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Introduce our own plane type to avoid using the libvda one in the
DecoderDevice interface.
BUG=b:169295147
BUG=b:161774071
TEST=Youtube video playback works on kukui-arc-r.
TEST=Youtube video playback works on hatch-arc-r.
Change-Id: I59e7dd0003a4fd5cb5cc10501f8167d8434addc2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2477406
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Use the decoder's own pixel format type to avoid using the libvda one in
the DecoderDevice interface.
BUG=b:169295147
BUG=b:161774071
TEST=Youtube video playback works on kukui-arc-r.
TEST=Youtube video playback works on hatch-arc-r.
Change-Id: I85589c25d337a517e4d98c55e8fb4e968c0c3e46
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2477405
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Replace the libvda profile type by the more generic crosvm format type
to make this part of the interface portable.
BUG=b:169295147
BUG=b:161774071
TEST=Youtube video playback works on kukui-arc-r.
TEST=Youtube video playback works on hatch-arc-r.
Change-Id: Ia0eb210278e4e4d945a4caa304c072ce68771440
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2477404
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Replace libvda::Result by the more generic VideoResult in the
DecoderDevice interface. Since all callers of the interface ended up
converting libvda errors into VideoErrors anyway, this turns out to be a
better fit.
BUG=b:169295147
BUG=b:161774071
TEST=Youtube video playback works on kukui-arc-r.
TEST=Youtube video playback works on hatch-arc-r.
Change-Id: Idc3be76ab312c95b9d234550270adef44ea86f3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2477403
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The virtio video decoder was working directly with libvda to
provide the video decoding service to the guest. In the future we may
want to add other ways of providing decoding support, like
software-based decoding (useful for testing the virtio device and the
guest support), or direct decoding using the host's native capabilities.
Introduce a DecoderBackend interface that the decoder will use to
perform the actual decoding, and start moving the libvda-related code as
an implementation of it. At the moment the interface still uses libvda
types for parameters and return values for the purpose of keeping the
change simple, but we will replace them in the subsequent changes.
BUG=b:169295147
BUG=b:161774071
TEST=Youtube video playback works on kukui-arc-r.
TEST=Youtube video playback works on hatch-arc-r.
Change-Id: I9d47cc934d34a0c706c2112831e827b6b1aa5d0a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2460526
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Enable ascii casefold support for the 9p server when requested on the
command line. Needed by arcvm.
BUG=b:162388795
TEST=`stat foo.txt` and `stat FoO.TXt` return identical results even
though only foo.txt exists
Cq-Depend: chromium:2498170
Change-Id: Icf507ac0d8413e7794fdd643296d507781897039
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2501545
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
The p9 crate API changed so that the new() function now returns a
result. Update the caller to match.
Additionally, the implementation also changed to use different syscalls
so update the seccomp filters to match.
BUG=b:162388795
TEST=Start a vm with a 9p mount and test the changed operations to make
sure they still work.
Cq-Depend: chromium:2494169
Change-Id: I7c4e1fd2fb192206402e895b09e519c3e769ae3c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2494328
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
... to allow configuring Gfxstream host renderer based
on whether or not the guest Android is using ANGLE as
its native OpenGL driver.
BUG=b:165022040
TEST=launch_cvd --gpu_mode=gfxstream
Change-Id: I566ed1e7590f7f3db99960440421fd65bba08f7b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2466604
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
This CL increases the maximum resolution in the virtio video encoder
from 1920x1080 to 4096x4096. While devices are typically not able to do
realtime encoding in huge resolutions, they are usually still supported
by the HW encoder.
BUG=b:168262411
TEST=Record using Camera test app in 1600x1200 resolution on hatch
Change-Id: I62bdead25861dd3384d7c9d8ad1a8877e5af3215
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2508094
Reviewed-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
This CL justs adds two very simple tests to improve overall test coverage.
Not sure what the best practices would be for mocking out the system
time, so I have skipped that functionality for now.
BUG=b:171750410
TEST=No change in functionality, just an added test.
Change-Id: I7a4e99c9d11203c5569ff28d2a5477bf8fd1b3a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2500948
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Previously the caller of ioapic::new was responsible for calling
register_irq_event on the IOAPIC's outgoing events. The MSI IrqRoutes
for these outgoing events used the same GSIs < 24 as the incoming
PIC/IOAPIC routes.
This worked for the split irqchip, because PIC/IOAPIC events are handled
in userspace and MSI events in the kernel, so there was no confusion
about which route an event should use. But with the userspace irqchip,
the routes have to be differentiated, otherwise incoming and outgoing
IOAPIC events with the same GSI trigger each other in a loop. Also,
registering all outgoing IOAPIC events upfront increased the number of
irq event tokens by 24, even though only a few outgoing events are used.
Now the IOAPIC is responsible for registering outgoing events and it
allocates new GSIs >= 24 for its MSI routes. An event and route are
only set up when a redirection table entry is configured with non-zero
MSI data.
BUG=chromium:1077058
TES=boots with split irqchip
Change-Id: I87c1df6150d50205810759ef152e1c9b33bcfe4d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2419672
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
There were some assumptions built into the hypervisor abstraction
implementations that we would only ever be registering a single Event
for any irq number, but that is no longer the case since 1d0f160. So
this change updates the hypervisor abstraction trait functions to allow
callers of irq_event_tokens to distinguish between multiple events that
refer to the same irq number using an IrqEventIndex. This index is then
used when calling service_irq_event.
Also, if register_irq_event would add a new irq event that the main
thread should wait on, register_irq_event will return the associated
IrqEventIndex. This change also updates linux.rs to use these changes.
The --split-irqchip mode may work even without this fix, depending on
which devices are sharing irqs. If the devices using shared irqs are all
virtio pci devices they may switch to MSIx mode and then not need their
original interrupt event.
BUG=chromium:1077058
TEST=disabled MSI mode on pci devices, forced additional irq sharing,
and verified that --split-irqchip mode still works + cargo test -p
devices
Change-Id: I4feb2817b6c477284ad463c0221d1f156813b6ce
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2405300
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
This simplies the complexity to deal with ownership and mutability,
while considering both the virtio-fs and regular FUSE use cases.
BUG=b:168305155
TEST=./build_test
Change-Id: Ic77d8e0b922e74a5733b99eeff41946177666c8d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2500944
Tested-by: Victor Hsieh <victorhsieh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Victor Hsieh <victorhsieh@chromium.org>
This involves removing RawFd trait implementations from
Event and Timer, and resolving the echoing dependencies from
there.
Ultimately, this results mostly in changes across ioctl
(new thin layer in base), kvm, msg_on_socket, and a few other
areas. As usual, most changes are negligible.
BUG=b:162363783
TEST=./build_test
Change-Id: I47dec94666bc3430fed627b4767919c9cb4fce6f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2462330
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
This is a layer above PollContext with a more generic interface.
As PollContext is used so widely, this is quite a large change
in order to accomodate the interface update, especially with the
use of RawDescriptor. In some cases this has caused an echo
of updates to RawDescriptor, which is fine because of our eventual
goal to move the whole codebase to it regardless.
Note there are a few instances of forcing the RawDescriptor update
chain to stop, ex. ioctl. This is to keep the scope of this CL
concentrated and avoid changing entire other areas.
Note that this CL leaves out a few additional pieces of work:
- The sole usage of EpollContext over PollContext (event_loop),
which poses a bigger challenge for interface changes
- Full PollToken renaming, which is a tiny change turned difficult
due to the unavailability of type aliases for traits.
- Renaming certain methods which have been updated to use
RawDescriptor such as keep_fds. Some have enough dependencies that
they are worth avoiding to keep this CL pointed, but will be
addressed in future CLs to make sure the whole codebase is on the
fd->descriptor train
BUG=b:162363783
TEST=./build_test
Change-Id: Iff2cfe8f90dea55f1388f8e91bdc698e121a8e43
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2455726
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
At CL:2494322, we moved the clearing output resources logic from
handle_provide_picture_buffers() to clear_queue(). That CL only
considered the resolution change case, but didn't handle the flush
case correctly.
When the userspace flush the decoding, it streamoff the output queue.
But VDA doesn't request new set of buffers, ProvidePictureBuffers()
won't be called. In this case, crosvm shouldn't clear the output
resources. Crosvm only needs to clear the set of queued resource ids.
Also, when VDA sends ProvidePictureBuffers() the first time, V4L2
output queue at the userspace is not streaming. So the userspace won't
streamoff the output queue. In this case, we also don't need to clear
the output resources.
BUG=b:171860073
TEST=pass android.media.cts.MediaCodecTest#testDecodeAfterFlush
TEST=pass android.media.cts.AdaptivePlaybackTest
Change-Id: I2a425c1fd9e61322d92dc54930dd88242c964de3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2505284
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
A prior CL (@81d5adbad7) removed VIRTIO_F_VERSION_1 from the features on
virtio-input, which causes boot failures on VMs that require those input
devices. This CL pipes protected-vm down to virtio-input & restores the
features.
BUG=none
TEST=builds
Change-Id: Ic54c7135c3ed4abf4c9d0a2c6969a0abaef7e7b4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2503486
Auto-Submit: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Will Deacon <willdeacon@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The current crate still require some work to be really reusable as a
regular FUSE, i.e. with a new reader/writer against /dev/fuse. This
change intends to focus on creating the crate, without trying to find
the optimal interface, and still keep virtio/fs working.
BUG=b:168305155
TEST=./build_test
TEST=USE='asan fuzzer' emerge-hatch crosvm
Change-Id: I8b623c9262221113b720c10125a6770763f14dc8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2466484
Tested-by: Victor Hsieh <victorhsieh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Victor Hsieh <victorhsieh@chromium.org>
Originally, we clear all the output resources when getting
ProvidePictureBuffers command from VDA. At this point only VDA
discards the output buffers. crosvm should keep the output resources
until the output queue is cleared.
Note that at crrev.com/c/2494602, GAVDA will ignore the output buffers
after calling ProvidePictureBuffers(). So it's safe that crosvm passes
the output buffers after getting ProvidePictureBuffers command.
BUG=b:171442927
TEST=pass android.media.cts.AdaptivePlaybackTest#testVP9_adaptiveDrc
Change-Id: I54dd364e7509c18fb3a3cd193da97dd107ceec44
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2494322
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
BUG=b:140082257
TEST=emerge-$BOARD crosvm
TEST=v4l2-encoder-sample
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm after crrev.com/c/2256525 (on hatch and eve)
Change-Id: I7f1c1bb6a8ba192ab7a598227e59fc9ec307ad8a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2167311
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Alex Lau <alexlau@chromium.org>
Commit-Queue: Alex Lau <alexlau@chromium.org>
The argument passed to get() and get_mut() is already a reference, so we
don't need to add another redirection to it.
BUG=b:161774071
TEST=Youtube video playback works on kukui-arc-r.
TEST=Youtube video playback works on hatch-arc-r.
Change-Id: I0d299c284c00b68160676332dcf5387aed078b7c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2484062
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This disables the VIRTIO_RING_F_EVENT_IDX optimization, which seems to
be causing I/O to sometimes not complete when used with the Linux virtio
block guest driver. The exact root cause is not clear (possibly a
race/memory ordering issue when reading and updating the event index),
but disabling the feature flag is enough to get back to a reliable state
while the failure is debugged.
The particular test case that triggers this typically reproduces as a
hung task in btrfs waiting for an I/O completion that never shows up.
With the EVENT_IDX feature disabled, I am not able to reproduce the hang
after many hours of running the test case.
BUG=chromium:1097385
TEST=Run reproducer test case; do not observe any hung tasks
Change-Id: Iaf37722f23c05276ec65f4d4a10c4a47af764538
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2486671
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Virtio 1.1 introduces the VIRTIO_F_ACCESS_PLATFORM reserved feature bit,
which allows the guest operating system to discover that a virtio device
has limited access to memory. In the case of Linux, this forces the use
of the DMA API for virtio transfers, which in turn can bounce data
through a shared window that is negotiated between the guest and the
hypervisor.
Advertise the VIRTIO_F_ACCESS_PLATFORM reserved feature bit when crosvm
is running with the '--protected-vm' option.
BUG=None
TEST=./build_test
Change-Id: I78e8d9e78999790059639b64611b8081c39d24ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2453560
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
bytes_written is a method of virtio::descriptor_utils::Writer. In order
to decouple from virtio, replace it and count the bytes inside the fuse
server.
Also replace some write_obj with write_all that were missed in 7ab6aac8.
BUG=b:168305155
TEST=./build_test
Change-Id: Ib38d13b317f5bca2b5549215f4cd7c2ffb975339
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2477248
Reviewed-by: Victor Hsieh <victorhsieh@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Victor Hsieh <victorhsieh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Victor Hsieh <victorhsieh@chromium.org>
This CL makes the following fundamental changes to cros_async:
1. Removes PollOrRing and replaces it with IoSourceExt, and the
subtraits ReadAsync & WriteAsync. The blanket implementation of
IoSourceExt has been dropped, and replaced with source specific
implementations of the trait. Those implementations are where
the code from PollOrRing has been moved.
2. Pinning for IoSource has been dropped from UringSource & the uring
futures. This appears to be safe because the IoSource doesn't contain
any self refs, or perform any operations beyond forwarding to the
RegisteredSource. (The FD is duped before being passed to
RingWakerState by RegisteredSource, so there doesn't seem to be any
data which would require pinning.)
3. U64Source was replaced by EventAsync.
It also switches all Error enums to use thiserror, which reduces
boilerplate.
BUG=None
TEST=cargo test -p cros_async
Cq-Depend: chromium:2421742
Change-Id: Ie1dd958da2e1f8dec1ae1fd8c0b4e754223d330d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2416996
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
libvda takes ownership of output fds, so don't maintain ownership and
attempt to close them within the decoder device.
Closing output fds twice was benign if the decoder device performed
the second close. However, if the decoder device closed an fd while
libvda's IPC thread was processing the fd, then the IPC thread's failure
to close the fd would trigger an assert. Note that because fds are
recycled, this could happen when the decoder was processing either
bitstream or output fds.
BUG=b:169535727, b:170451397
TEST=android.media.cts.AdaptivePlaybackTest#testVP8*
Change-Id: I06c5b7d117dc4057cbd01bdb90167f7f23ab336e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2473978
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alex Lau <alexlau@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
All virtio devices pass VIRTIO_F_VERSION_1 explicitly. In preparation
for passing additional reserved feature bits, introduce a free function
so that devices only have to worry about device-specific features.
BUG=None
TEST=./build_test
Change-Id: Ifcf309fa010ea518b17b047b0e95e5ad5c7522bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2453558
Reviewed-by: Andrew Walbran <qwandor@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Will Deacon <willdeacon@google.com>
This allows code to create references to traits such as `&dyn Vcpu` for
`&dyn IrqChip`. This also allows keeping such traits inside of opaque
`Box` like wrappers.
To achieve this, trait methods referencing `Self` have an additonal
`where` clause that restricts them to sized types. Associated types are
removed and replaced with their trait equivalents (as parameters) or an
opaque Box (as return values).
To work around certain cases where a concrete type is needed, such as
for KVM based `IrqChip` impls, the `downcast_rs` trait is used to allow
`dynamic_cast` style casting.
The binary size impact of this change is small. For comparison, here is
the size change with this commit:
armv7a -0.49% (-9 kiB)
aarch64 -0.17% (-3 kiB)
x86_64 +1.77% (+40 KiB)
BUG=None
TEST=build_test
Cq-Depend: chromium:2466660
Change-Id: I1a408734832d2971ea2979c1bc64b2ffe051b02d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2439298
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>
