Deactivate command is used when the CoIOMMU driver in the guest
is failed to probe, or CoIOMMU device is removed by the guest.
But these are not expected to happen. Once this happened, the
guest won't be functional as all the pass-through devices on top
of CoIOMMU will not work. So in the backend side, just panic when
receive such command.
BUG=b:188481989
TEST=Boot a VM with coiommu and remove it in the guest.
Change-Id: I912c71d80e6cbd02bf7edc6bfb30ef11051dc490
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292939
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Add a crosvm parameter to allow user to sepcify the coiommu unpin
policy. Besides unpin the pages when balloon inflate, coiommu also
supports to periodically unpin with a LRU policy.
The usage is like this:
"--coiommu unpin_policy=lru,unpin_interval=10,unpin_limit=8192"
which means to use LRU unpin policy with unpin interval is 10 seconds
and the unpin count limit for each cycle is 8192 pages.
Without specify the parameter, coiommu will use the default
configuration which is to turn off the periodically unpin.
BUG=b:188481989
TEST=Boot a VM with coiommu lru unpin policy + pass through devices.
Change-Id: I10414cc6b2520b804685450dfd1560cfe49455a7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292938
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
LRU unpin policy is an internal unpin policy which is triggered by
a timer. This policy can be used when there is no external balloon
unpin request.
BUG=b:188481989
TEST=Boot a VM with coiommu enabled + pass through devices.
Change-Id: Icb6e19073cb668fa954aec97e02be77f1b8f6a04
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292937
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Put the VFIO pass-through devices and coIOMMU creating earlier
than the virtio device so that when creating virtio-balloon
it can use the tube from coIOMMU to send the unpining request
when processing the inflate.
BUG=b:188481989
TEST=Boot a VM with Network device pass through w/ coiommu, and do
the iperf test. Then perform balloon inflate/deflate.
Change-Id: If3ff9b3b0293ce49a39498a18feae1d697523f92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292936
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Coiommu can be enabled through the command line. E.g.
To enable coiommu for a VFIO pass-through device:
--vfio=/sys/bus/pci/devices/0000:00:02.0,iommu=coiommu
BUG=b:188481989
TEST=Boot a VM with a VFIO pass through device w/ coiommu
TEST=Boot a VM with a VFIO pass through device w/o coiommu
Change-Id: Ica6145d7bc6a4c398f0fc10899f8ee24138615c4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292934
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
When balloon to do inflate to release some memory to hypervisor, such
memory should also be unpinned by the component(e.g. coiommu) which
has pinned these memory. This tube will be used by balloon to send
the unpin request to the components(e.g. coiommu) to do the unpin
before releasing the memory.
BUG=b:188481989
TEST=Boot a VM and check balloon inflate/deflate
Change-Id: I06aa8bd8c11deeac9f133adbefa6442cf1b722de
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292932
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
The memory pinned by coiommu cannot be release to hypervisor unless it
is unpinned. The balloon in VM will be used to inflate and release
memory to hypervisor. The tube added for coiommu will be used by balloon
to send the unpin request during inflating.
BUG=b:188481989
TEST=Boot a VM
Change-Id: I2c75346b721ac639c803490f8850a1ee03e74194
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292933
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
If crosvm register a req_irq eventfd on a vfio-pci device, kernel
vfio-pci driver will trigger this req_irq eventfd when the physical
device is removed from host.
So crosvm should register and monitor req_irq eventfd for vfio pci
device hotplug out, once req_irq eventfd is triggered by host
vfio-pci driver, crosvm should should inject an hotplug out interrupt
into guest, then guest device driver will be unloaded, finally host
vfio-pci driver will be unloaded and physical device is removed from
host.
BUG=b:185084350
TEST=Boot a guest and hotplug in/out pcie device repeatedly
Change-Id: Ia6e4c74b0ad5e87a4d2bea5631ef81e7120e07cb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3062742
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The unpin page framework will be used to handle the unpin request.
BUG=b:188481989
TEST=Boot a VM
Change-Id: I6d19a679c4626b8775d81e09ecca2a0fe6c58ec8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292931
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Coiommu is a virtual PCI interface device. It provides pin page
functionality to the guest VM for the pass-through device through
the VFIO framework. With this, the guest VM doesn't need to pin pages
at the VM creating time but just need to do this through coiommu
frontend driver dynamically at runtime. Coiommu frontend driver will
send the pin request to the backend through device MMIO with the GFN
address. Backend then find out the proper HVA according to this GFN
and map this GFN to the HPA finally through the VFIO framework.
Unpin page functionality will be supported in the next patches.
BUG=b:188481989
TEST=Boot a VM
Change-Id: Iac347200305ed0cebe1456e3a0a353de83e6c80b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292930
Reviewed-by: Chirantan Ekbote
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Extend with read_only support so that the user can create a
read-only map for some read-only memory region, like read-only
memory backed MMIO bar.
BUG=None
TEST=Boot a VM
Change-Id: Ia6c1fd365808991f02298f7bbfaac0be8c801f8b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292929
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Use the PCI address function field to evenly distribute the chosen
interrupt line across the available pins.
This does not change behavior when all devices are allocated on a
separate device number (they will all have function 0 and therefore
choose interrupt pin A, as they do already).
BUG=b:210795995
TEST=boot crosvm with multi-function devices
Change-Id: I4b3e525ef784ac41b3f66cfddea192dd933d9907
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3343181
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Each device does not know whether it is a multi-function device when it
is created; this is only possible to determine once all devices have
been added to the PCI bus. Change the PCI root code to check for this
and update the multi-function bit dynamically at runtime.
The multifunction option for the stub PCI device is also removed; it
will be determined automatically, so there is no need for the user to
specify it.
BUG=b:210795995
TEST=boot crosvm with multi-function devices
Change-Id: Iff8306a41bb2bf23f97f45d29edc7791efc754bf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3343180
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
GET_PARAMS and GET_PARAMS_EXT's reply can be delayed if a session is
ongoing but no input buffer has been received yet. When this happens we
store the command into a set of pending commands, but when doing so we
only allowed for a reply to GET_PARAMS to be returned, which causes the
wrong reply to be sent if the guest used GET_PARAMS_EXT. Fix this by
storing whether the EXT variant has been used as a boolean in the
command and replying accordingly.
BUG=b:193202566
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes without https://crrev.com/c/3349429
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes with https://crrev.com/c/3349429
Change-Id: I6d135c611a32d0f107ac9f437b046f4309b54dba
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3382501
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Knowing the decoding method used on the host can be useful to the guest,
e.g. in order to decide which format to use for buffers or to choose
between several acceleration options if more than one decoder or encoder
device exists.
Since this change only adds additional data to the device configuration
space, it does not introduce any incompatibility with existing guests.
BUG=b:161774071
BUG=b:169295147
TEST=Android Youtube plays properly on Hatch.
Change-Id: I2ba47504c17cefbceef16ccacc211856ef9fa30e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026356
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The features supported by a video device will depend on the backend in
use. For instance, the libvda backend only supports virtio objects for
memory buffers, whereas the ffmpeg backend will support both virtio
objects and guest pages.
BUG=b:209523781
TEST=Android Youtube can play videos on Hatch.
Change-Id: Ib55d959ae6a6d446d8ce0b75b411e50bc40204f9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3143584
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This change adds a command line parameter for instantiating a VVU proxy
device.
BUG=b:194136484
TEST=Test with sibling VM with Vhost master connecting to a device VM.
Change-Id: I5ff56e6f1ebca5a7078eca3d951ddbfd411d14fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3290381
Reviewed-by: Chirantan Ekbote
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
Having to create a Box for each backend failure is cumbersome. Add a
backend failure creation method that takes care of this for us.
BUG=b:161774071
TEST=Android Youtube can play videos on Hatch.
Change-Id: I3f290504820f855c30b17364c3cbc9997ad74b36
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3308317
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Add a method that allows to conveniently map resources into a linear
buffer, even if the resources are initially sparse (as is often the case
with user memory).
BUG=b:209523781
BUG=b:169295147
TEST=Android Youtube can play videos on Hatch.
Change-Id: If9a9b7764e6522da20d85e2ebca59a77b58573ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3308315
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Supporting guest memory is necessary for many guests that expect to
render into guest-allocated memory (as opposed to the virtio-object
method that is for now rather specific to Chrome OS). Add support for
this kind of memory in the form of SG lists.
BUG=b:209523781
TEST=Android Youtube plays properly on Hatch.
TEST=v4l2r's test decoder can allocate MMAP buffers.
Change-Id: I9864113ca2b88a23db8204ee7dd8d38801857c25
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2982247
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The current code assumes that we will only ever have one entry per
memory resource, which is accurate for now, but doesn't allow us to
support memory pages resources (which can have several entries) or
multi-planar formats.
Fix this by reading the actually expected number of resources and
passing them to the device in a double-vector containing one set of
entries per memory plane.
BUG=b:209523781
TEST=arc.VideoDecodeAccelPerf.h264_1080p_30fps_vm passes on zork-arc-r with crrev.com/c/3358090 applied to the guest.
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on zork-arc-r with crrev.com/c/3358090 applied to the guest.
Change-Id: I984ee49c588c3a188e72bc04bc7f568f582523f5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3379629
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The current naming is a bit confusing: a resource is one or several
buffers that are each made of one or several entries. The elements that
we return to the device are thus resource entries (that need to be
resolved into a single resource) and not the whole resources themselves.
BUG=b:209523781
TEST=cargo build --features "video-decoder,video-encoder"
Change-Id: Ie3d89c48f9b3e7758b455ea1b2d4954daf248d0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3379628
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
On the guest side application using V4L2 frontend can query frame
sizes using VIDIOC_ENUM_FRAMESIZES ioctl. This ioctl accepts pixel
format as an argument. It is correct to query frame sizes for input
format. In this scenario virtio-video would always return 0x0
resolution provided by crosvm, which is incorrect.
This patch fixes this issue by suppling correct frame sizes into
returned input formats.
BUG=b:160440787
TEST=tast run eve arc.Video*
Change-Id: Ib12b19ca515056aa8fa9470ece34309db2475817
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3377642
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Marcin Wojtas <mwojtas@google.com>
Device gets irq_num from system_allocator when device is added, this
irq_num should return to system_allocator when device is hotplug removed.
this commit adds a ReleseOneIrq interface into VmIrqRequest, it release
one gsi into system_allocator. So vfio-pci device could call it at device
close function.
For msi and msix interrupt vectors, they have irq tube already and could
call ReleaseOneIrq easily.
For legacy INTx, the gsi for vfio-pci's INTx is gotten from host, and this
gsi maybe share with other device, so the commit doesn't release this gsi
at vfio-pci device's remove, otherwise the gsi shared device will be broken.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio pci device repeatedly
Change-Id: Ibcca226b4b5b2092b5bc94bef8219eea82979086
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955580
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
When a hotplug vfio-pci device is attached to a bridge parent, kernel will allocate
mmio from its parent's bridge window, so crosvm doesn't need to allocate it.
But previously mmio_regions is used to track existing bar's address and size, but this
commit doesn't allocate mmio, so the initial bar address in mmio_regions is zero,
so this exception should be handled in bar's reallocation code that address 0 isn't
a valid bar address.
BUG=b:185084350
TEST=Hotplug in and out vfio-pci device in a vm repeatedly
Change-Id: I1a082b02065d42eccf46e24941727edf7b6355a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3319707
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
For bridge's memroy and prefetch memory window, current the limit is
smaller than the base, this means pcie rp doesn't support this window,
but OS still allocates 2M memroy window and 2M prefetch memory window
for it, this has two problems:
a. kernel allocates mmio, but crosvm's system allocator doesn't capture
this allocation and crosvm still use system allocator to allocate mmio
for hotplug in device, so it may have conflict between kernel and crosvm.
b. the 2MB window is too small, as the added device behind this bridge
is allocated mmio from this window by kernel, if device required mmio
is large than 2MB, the device couldn't work.
This commit preallocates 8MB memory window and 64MB prefetch memory window
for one pcie rp, and let kernel allocate mmio for its children devices
from this window, kernel also maintains the allocation and free of this
window, crosvm system allocator doesn't care about which device own the
segment of this window.
BUG=b:185084350
TEST=Boot a guest and check pcie rp bridge window's base, limit and size
Change-Id: I566a2d81b458da1d2d5f07b689fa898453586adc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3319706
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Motivation: get rid of required options vs help boilerplate
BUG=n/a
TEST=run_tests
I've also done some binary size testing as well:
Baseline:
text data bss dec hex filename
5050303 264640 1072 5316015 511daf crosvm
StructOpt:
text data bss dec hex filename
5400901 277104 1072 5679077 56a7e5 crosvm
StructOpt, default-features = false
text data bss dec hex filename
5418437 275872 1072 5695381 56e795 crosvm
argh
text data bss dec hex filename
5024287 262648 1072 5288007 50b047 crosvm
Change-Id: I7ebe09e38d3854c4a0e5c8e3a2aecb123652ce1e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3339792
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Anton Romanov <romanton@google.com>
Auto-Submit: Anton Romanov <romanton@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Anton Romanov <romanton@google.com>
Currently the crosvm encoder device only supports single-buffer frames,
yet the encoder requires as many buffers to be submitted as there are
component planes in the frame (e.g. 2 for NV12).
This is incorrect and in effect the encoder ignores all but the first
plane, but nonetheless it expects the number of submitted buffers to be
equal to the number of component planes. This makes it impossible to fix
the issue at the kernel level using http://crrev.com/c/3358090.
Change the expectation about the number of buffers to support both
single-planar and multi-planar submissions. That way we won't break the
encoder while fixing the problem on the guest side.
BUG=b:212214039
TEST=arc.VideoEncodeAccel.h264_192p_i420_vm passes on zork-arc-r.
Change-Id: I62763a9dd754697eaab0bae421604a25b0a2f7d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3358440
Reviewed-by: David Staessens <dstaessens@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This fixes a bug introduced by [1] when removing vfio device and
'device_num' is zero.
A panic occured when unplug a vfio device:
[ERROR:src/panic_hook.rs:90] thread 'crosvm_vcpu4' panicked at 'attempt to subtract with overflow', devices/src/vfio.rs:462:9
The variable group.device_num is 0 when subtract. And when initalizes a
vfio device from hot-plugging workflow, 'group.add_device_num()' is
missing.
BUG=b:185084350
TEST=hotplug in and out a vfio-pci device in guest repeatedly
[1]: 7b80554473
Change-Id: I9a039cd15e9f9414a4a0501c64da13be76e59c1b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3365212
Reviewed-by: Xiong Y Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This is useful mostly for development and testing.
BUG=b:209795495
Change-Id: Ie8c4dfade2cbc770daa7d97e22b1574fdf895a19
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3330210
Reviewed-by: Will Deacon <willdeacon@google.com>
Reviewed-by: Chirantan Ekbote
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This involves two main changes:
* Protected VMs must be created with KVM_VM_TYPE_ARM_PROTECTED.
* pVM firmware is now loaded by IPA rather than memslot ID.
There are also a lot of trivial changes because the ProtectionType enum
was moved from the devices crate to the hypervisor crate.
BUG=b:209794844
TEST=Will tested manually with patched kernel and dummy firmware
Change-Id: I1dd75e20063ca4736f155292ca5f70b94664fdd9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3330204
Auto-Submit: Andrew Walbran <qwandor@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Since users of `DeviceRequestHandler` don't match on `HandlerError`
enum, there are no advantages on using thiserror. So let's switch to
anyhow.
BUG=none
TEST=cargo test
Change-Id: I6d4697e174a4e587c52ec71ef99b453e1d00cc35
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3353058
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Add utilities to bind a vfio-pci device, which will be used in
the virtio-vhost-user driver.
This works like the following use of DPDK's devbind script [1].
$ dpdk-devbind -b vfio-pci 'Bus:Slot.Func'
[1]: https://doc.dpdk.org/guides/tools/devbind.html
BUG=b:194137301
TEST=cargo test in devices
Change-Id: I67fb34ae2ad55320231751ea553a2094bb8cdde4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3295303
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Abhishek Bhardwaj <abhishekbh@chromium.org>
Auto-Submit: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
The commit broke the chromeos build. The fix forward is easy, it's
just a typo and a reminder we really need to get libvda code compiling
in Kokoro.
BUG=b:210749428
TEST=emerge-amd64-generic crosvm
Change-Id: I47e0c0b8f843e8b66c00513221b58c6197fe644b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3352172
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Make the decoder able to switch the resource type of its queues when the
new S_PARAMS_EXT command is used.
BUG=b:193202566
TEST=Youtube can play videos on Hatch.
Change-Id: I1ff3c15ae1924c2fdf1b99af9ea24716f17c864f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3340692
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Originally the resource type of both the input and output queue needs to
be provided when the stream is created.
This however does not work well with guest drivers that allow to change
the memory type being used for buffers after the stream is created, e.g.
V4L2.
To mitigate this, allow to specify the resource type as part of the
stream parameters by introducing new GET_PARAMS_EXT and SET_PARAMS_EXT
that work exactly like the original ones, but handle the resource type
in addition. The old commands are still supported to preserve
compatiblity with guests relying on the old commands.
BUG=b:193202566
TEST=Youtube can decode videos on Hatch.
Change-Id: I84277f8b82773a1d8f4f99bb5050345320807cad
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3143583
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This is a more accurate name since the object does not initially come
from the guest.
BUG=b:161774071
BUG=b:209523781
TEST="emerge-hatch chromeos-base/crosvm" passes.
Change-Id: I618419dc7cfb7203669a5c72b015d5acea50ff24
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3340693
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This CL adds support for the new GAVD backend that connects directly to
a Chrome media::VideoDecoder through the new mojo::VideoDecoder
interface. The mojo::VideoDecodeAccelerator interface currently used by
the GAVDA libvda backend is deprecated and will be removed in the
future.
To enable the libvda GAVD backend the "--video-decoder=libvda-vd"
argument needs to be provided to crosvm.
BUG=b:189278506
TEST=arc.VideoDecodeAccel.h264_vm
Change-Id: I8383bbc1e4371093bde7b0385efc51752c7bc466
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026654
Auto-Submit: David Staessens <dstaessens@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The memory type of resources is a per-queue property, so move it here.
On top of making sense, this will also allow us to extend the
virtio-video protocol to support changing the resource type as part of
the parameters, which is something we need to do in order to support
both guest memory and virtio objects as resources.
BUG=b:193202566
TEST=Youtube can decode videos on Hatch.
Change-Id: I4315292a33d4f145d815fef44803881002d59c3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3340691
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
When a file descriptor is returned from the poll context that has the
hungup flag set, it should no longer be polled. Remove it from both the
poll context and the map of handlers when hangup occurs.
Additionally, instead of stopping the whole event loop when an event
handler error occurs, just remove the failing event handler from the
watched set and continue. This should improve robustness of the USB
controller emulation.
BUG=chromium:1278424
TEST=Share USB device with Crostini via vmc, then physically unplug
Change-Id: Iccaae0ea24b43d0b5e593ca2fe4418eb3892300a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3335302
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Previously, if any event handler in the event loop failed, it would
print a generic "event loop stopping due to handle event error" message
and stop working. This is not particularly useful for determining which
event handler actually failed. Instead of returning an empty Err, use
anyhow::Context to associate each potential failure with a
human-readable error string.
chromium:1278424
TEST=Cause USB event loop failure, observe more useful message
Change-Id: I438a96bf757946efbd03a99ef0e17dfbf0d4e1c8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3339793
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Improvements:
- Once a {playback, capture} stream is initiated.
We should start write (read) audio in each callback period or
the underlaying audio server will underrun (overrun).
(Even in the WorkerStatus::Pause state).
- Change the polling loop logic to
wait for next buffer
-> check status
-> try_next desc_chain or exit
-> transfer data or exit
And make start_pcm_worker act like real audio hw device, which
consumes data in every fixed period.
- Right before leaving from WorkerStatus::Quit, we still need to
transfer data to/from the running stream to prevent
underrun or overrun.
Changes:
- changes in start_pcm_worker:
- extract read_data, write_data utils
- implement From<Result<()>, Error> for virtio_snd_pcm_status
- poll next_{capture, playback}_buffer
- if status == WorkerStatus::Pause, still need to transfer data to
prevent underrun or overrun
- split Output and Input stream logic
- use copy_from or copy_to instead to io::copy
- remove Condvar usage
- changes in audio_streams
- add copy_from in AudioBuffer and AsyncPlaybackBuffer
- add copy_to in AudioBuffer and AsyncCaptureBuffer
BUG=b:210197743
TEST=alsa_conformance_test and make sure there is no
`ERR cras_server[1818]: Error reading msg from client: rc: -104` or
`ERR cras_server[1818]: fetch err: -32 for 6490001`
errors.
Change-Id: I004969040881cb2d46b54589e3e7e634ea67d152
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3341135
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
This change caches the parameters received in the activate method. It
spawns a Worker thread to process Vhost master communication.
Furthermore, it forwards all non-action messages to the Vhost slave.
BUG=b:194136484
TEST=Compile.
Change-Id: Ie853add605ea4daa1c62ec9ce93cbac083e57de7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3288870
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Abhishek Bhardwaj <abhishekbh@chromium.org>
It was renamed to VIRGL_RENDERER_RENDER_SERVER in virglrenderer.
BUG=b:177267762
TEST=run vk and gl apps on volteer
Change-Id: Ic00be726e720686023ab90e611df67b4e733beb9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3331737
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chia-I Wu <olv@google.com>
