The current way for building a codec device is to call the corresponding
constructor method of the backend we want to use. However doing this
forces us to pass the resource bridge to these constructors, introducing
dependencies from the backend to parts of the code that are not used
otherwise.
Switch the construction method to one constructor per backend, which
only takes the arguments relevant to the backend, and one device
constructor that takes the backend to use as parameter.
BUG=b:161774071
BUG=b:169295147
TEST=Android Youtube plays properly on Hatch.
Change-Id: I493f421e982a1d2ba8292a69bae575afeee17e4c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026349
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
We have two separate features for video decoder and encoder, but
selecting any of them results in all the video code being included. Add
some #[cfg] statements to compile out the unneeded code if only one of
the features is selected.
BUG=b:161774071
TEST=`cargo build` passes without warning
TEST=`cargo build --features "video-decoder"` passes without warning
TEST=`cargo build --features "video-encoder"` passes without warning
TEST=`cargo build --features "video-decoder,video-encoder"` passes without warning
Change-Id: I3e5f2173695ee9dd5e8d26ace14374d426e570a6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026347
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Make the backends accept our generic resource types as inputs instead of
expecting virtio objects. This makes the backends able to deal with any
kind of resource, the counterpart being that they must now check what
kind of resource they received. The VDA can only deal with virtio
objects and will reject other kinds of resources.
On top of making backends not limited to virtio objects, this is also
safer than passing FDs because it becomes clear when we are transferring
ownership of a resource, and when we need to clone them. Also since
resources carry information about their layout, the number of arguments
we need to pass to the backends is reduced.
BUG=b:161774071
BUG=b:169295147
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
TEST=GtsExoPlayerTestCases com.google.android.exoplayer.gts.DashTest
passes on hatch
Change-Id: I09dd81bac13a46fa908a4107a376fa7d59fb9759
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983096
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Currently the video device only accepts virtio objects (as file
descriptors) for resources, and file descriptors are hard-coded a bit
all over the place to represent buffers and frames. This causes two issues:
1) Multiple buffers cannot currently be used to represent frames, i.e. 1
frame is exactly one virtio object,
2) Resources that are not virtio objects, like guest memory, cannot
be used at the moment.
This patch introduces more flexibility in the way resources are handled:
first, all the resource-related code, including their resolution using
the resource bridge, is consolidated into a new resource module. Then,
the command module does not arbitrarily decide that all resources are
virtio objects, and leaves that decision to the queues. Finally,
resources now have their enum type that can unfold into any of the
resource types we will support (currently only virtio objects). This
forces consumers of resources to check their type before using them.
Semantically, very little should change. The only noticeable side-effect
should be that we now call the resource bridge only once per input
buffer instead of once per decoder operation.
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: I93b203117b5c96e91d4f1b8007e95ec5c501ea5f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983095
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The crosvm video device cannot currently work with resources that have
more than one memory/object entry. Enforce this rule at the command
level.
BUG=b:161774071
BUG=b:169295147
TEST=Android Youtube plays properly on Hatch.
Cq-Depend: chromium:3247491
Cq-Depend: chromium:3247492
Change-Id: Ibfe2e420b4a77062cca940c5e97e7053aa4b76a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026345
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
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>
