It's a simple enum, so it should be Copy.
TEST=tools/dev_container tools/run_tests
TEST=tools/dev_container tools/run_tests --target=vm:aarch64
Change-Id: Ieeacedb10fa6a93d6cdd9878097c66aa936f8e30
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3420329
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Add a crate containing an API for controlling the balloon. This is done
by reusing the API between the control socket and the balloon device.
BUG=b:213962590
TEST=compiles
Change-Id: I5d89d5ebee55162d28ba45ca2c49b7083561b916
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3394440
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Fix a few compilation warnings in our tests:
* The PCI device had an unused argument without a leading underscore in
the name ;
* The virtio queue is dereferencing null pointers, which is UB albeit
technically ok in this case (bindgen generates similar tests too [1]).
[1] https://github.com/rust-lang/rust-bindgen/issues/1651
BUG=None
TEST=cargo test in devices/ does not show these warnings anymore.
Change-Id: Id272b5381f80bb72d96839a5a6da8bb0c644502d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3418623
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The patch also adds files to skip building and testing crates on
windows. When we run
```
tools/windows/build_test.py --skip_file_name .windows_build_test_skip
```
the build/test succeeds without actually doing anything as build/test
for all crates is skipped by creating '.windows_build_test_skip'.
Bug: 213170957
Test: Ran script on downstream repo
Change-Id: Iebd2cea463ee722be4feaed88229e1fb5e9fd6c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3417918
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Vikram Auradkar <auradkar@google.com>
The tool is added to ./tools/fmt which will be called during
./tools/presubmit as well as by Kokoro during testing.
This requires a new dev container version to bundle the mdformat
tool in the container.
Note: mdformat does not have any IDE integrations, but the prettier
plugin with prose-wrap enabled and a line length of 100 provides
almost identical results.
BUG=None
TEST=./tools/fmt --check
Change-Id: I0ae5659eff8555df7c85c70e62095a1e116b98da
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3416098
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Add an init-mem parameter that limits how much memory the VM can use on
startup. If set, the balloon is inflated on startup to (mem - init-mem).
BUG=b:213962590
TEST=set param and verify balloon inflates on startup
Change-Id: I920bf9cfa26081ee544219406f8cf9827ff84bfa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3394439
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
The picture buffer size was computed from the size of the visible
rectangle, which is potentially incorrect: if the origin of the visible
rectangle is not (0, 0) then the buffer is going to be larger.
Fix this by using the provided coded width and height, which correspond
to the actual size of the buffer and not just its visible area.
BUG=b:161774071
TEST=Android Youtube decodes properly on zork-arc-r.
Change-Id: I80e15248f41d6202190456d2ab61f8f50d3b6ebb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3412457
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The pages which are frequently used by the VM are likely not to be
unpinned. So an optimization is to skip the unpin scan for those pages
in the LRU unpin policy. The unpin_gen_threshold defines a threshold
number that, if a page cannot be unpinned in a period of
(unpin_gen_threshold* unpin_interval) seconds, then this page will be
marked as inactive. Those inactive pages will be scanned every
(unpin_gen_threshold* unpin_interval) seconds if there is no enough
active pages to unpin.
BUG=b:188481989
TEST=Boot a VM with coiommu lru unpin policy + pass through devices.
Change-Id: Ie020173097b6f4f925cafc121a802243ef65f165
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292941
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Unpin is handled indepently with the coiommu frontend driver. To
support the DTT shrinker happened in coiommu, it needs a way to
park the unpin thread for a while in case unpin is also accessing
the DTT. When the shrink is done, frontend can unpark to make unpin
thread work again.
BUG=b:188481989
TEST=Boot a VM with coiommu lru unpin policy + pass through devices.
In VM, use command #echo 2 > /proc/sys/vm/drop_caches to trigger
shrink.
Change-Id: Icea6aee6424f09339b549eb2735c73551a87a505
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3292940
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
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>
