Previous commit "devices: Add/Remove device mmio at config memory enable
/disable", it has an assumption that when driver update bar's location,
driver should disable bar's memory/io at first.
But some driver reallocate bar's address even with memory/io enabled,
this commit monitor bar's config write, if address is modified, it
return this modification.
BUG=b:174705596
TEST=boot a vm, monitor resource reallocation and check function.
Change-Id: I9aa883192f5e2fec344d3e86c818c7a29287f49a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3184726
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
get_bar_configuration() returnis bar's info, this ignores memory/io enable
bit. Usually driver disable memory/io first, then wrtie 0xFFFFFFFF to
probe bar's existence and size, finally write real address and enable
memory/io.
if get_bar_configuration is called after mmio/io disabled, current
it may return invalid info. In order to filter these invalid info,
this commit checks memory/io enable bit, only return info at memory/io
enabled.
BUG=b:174705996
TEST=carto test -p devices
Change-Id: Ib8bf1a7f7f959025117f319f8f6c5a9e5efea2e2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3252779
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When initializing the device for encoding the underlying encoder
session is immediately brought up, as this is required to determine
parameters such as the desired output buffer size. This causes further
configuration changes to be refused, even when the device isn't
encoding anything yet. This CL makes changes to allow configuration
changes by recreating the encoder sessions as long as no buffers have
been queued.
BUG=b:203608233
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: I7e9d8b41ea2497b5d86aaca7db7ed13af056f11d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3252185
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
We need the access id for some future changes that will be posted soon
for a userspace irqchip.
Each vcpu will have a clone of the Bus itself, not the Arc<Bus>, so that
they can each have their own access id.
This also adds a call to set_access_id to run_vcpu.
BUG=b:160610704
TEST=ran local presubmit, and ran test image
Change-Id: I4afb0ef9c234f25150ce2f89d6fb228ad5b88745
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3261627
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
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>
