Two examples are added. A simple one and one with network
configured.
The examples are written in a way they can be integrated
with the mdbook to form a tutorial. This will ensure the
tutorial code snippets stay up to date.
The documentation for networking is added after
https://crrev.com/c/3237468 is merged.
BUG=b:214104901
TEST=./tools/examples/example_simple
Change-Id: I33682878858d8a0324fbb6a87e33cd55b29811b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3388063
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Tested-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
The newly-added KVM_CHECK_EXTENSION call to retrieve
KVM_CAP_ARM_VM_IPA_SIZE was checking for errors by looking for return
values less than 0, but KVM_CHECK_EXTENSION returns 0 for unknown
extensions (e.g. on older kernels before this extension was introduced).
Treat 0 as unsupported as well so the default 40-bit size is returned in
this case.
BUG=b:215174283
BUG=b:210727578
TEST=Boot crosvm on kevin (arm device with 4.4 host kernel)
Fixes: 891ea3e88a ("aarch64: limit high MMIO addresses to VM phys addr range")
Change-Id: I19a3ae00862882c030c1e776cb3ca10edeffd339
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3399344
Reviewed-by: Dennis Kempin <denniskempin@google.com>
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>
Mirroring Linux kernel behavior, we would like to have devices emit
MT (multitouch) events, and have these generate simlated ST events.
BUG=b:201796434
TEST=recreated kernel,virgl etc configuration from @ryanneph to confirm
Change-Id: Iaac625358bddefb7dfe0037c91ababdc30185cdd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3330723
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Maciek Swiech <drmasquatch@google.com>
Libvda can only be successfully used and linked against on Chrome OS.
Making the video decoder and encoder depend on it makes it impossible to
use these features on non-Chrome OS platforms. Remove the libvda feature
by default since the Chrome OS builders have been updated to enable it
explicitly.
BUG=b:161774071
TEST="cargo build --feature "video-decoder,video-encoder" fails.
TEST="cargo build --feature "video-decoder,video-encoder,libvda"
succeeds and embeds the libvda backend.
Cq-Depend: chromium:3023696
Change-Id: I54d31312e87e5d9a8e5c1a39955416bf892270d5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026352
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@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>
Since we have a chain of commits, we need to set all of
them to CQ+1 for the dry run to happen.
Unfortunately, the CQ will only ever run a single build
for a chain of commits. So the dry run will only happen
when all builds have finished.
BUG=b:213932296
TEST=./ci/kokoro/simulate build-merge-into-chromeos.sh
Change-Id: I1883b22ab97da604a4188528ccfb3231a23cb7f2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3384220
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Dennis Kempin <denniskempin@google.com>
... to add the `gfxstream_callbacks` param which was added in
aosp/1927497. This param is only used in specific forks of Crosvm
but is present in the common Gfxstream project.
BUG=b:214097104
TEST=launch_cvd --gpu_mode=gfxstream
Change-Id: I3870692dd7ea55653c9761e787ff747d20df44d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3381902
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alistair Delva <adelva@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Andrew Walbran <qwandor@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
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>
We can use the gerrit api to detect previous merge commits
the bot has made, then use those as the base for the next merge.
This will create smaller merges and is easier to manage as we do not
have to abandon so many changes.
One complication is detecting possible cherry picks the oncall may
have added to the previous merge commit.
Only open merge commits are taken into account.
BUG=b:213932296
TEST=./ci/kokoro/simulate build-merge-into-chromeos.sh
Change-Id: I795109be4c45bec49068c3e292a3947505755442
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3381832
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Dennis Kempin <denniskempin@google.com>
The comment above indicates that it was intended to be loaded at an
offset of 8 megabytes, but it was missing a zero, so it was being loaded
at an offset of 512 kilobytes instead. Fix the constant to match the
comment.
Fixes a warning from newer kernels:
Kernel image misaligned at boot, please fix your bootloader!
BUG=None
TEST=Boot Linux 5.10 on trogdor64, verify no error in dmesg
Change-Id: I2650d23458a13adff89a7f214734866c47d6f7cc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3364972
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Andrew Walbran <qwandor@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The high MMIO region of the system allocator was previously set up with
the upper limit of 2**64 - 1, but physical addresses on actual systems
are not that large. Now that pmem allocates from the upper end of the
high MMIO region, the size of the allocator actually matters.
Limit the aarch64 high MMIO allocator to the VM's physical address size
so that addresses at the end of the allocation range are usable and pmem
devices can be created on aarch64.
BUG=b:210727578
TEST=Boot with pmem device on aarch64
Change-Id: I67962c2b03f0f265349ae889c988eb69ef526f4a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3366858
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Andrew Walbran <qwandor@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The get_high_mmio_base_size() function duplicates and hard-codes the
math from get_platform_mmio_base_size(). Since these are both only
called in one location now, pull them into get_resource_allocator() so
the plat_mmio variables can be used instead of duplicating the math.
Also reorder the SystemAllocator::builder() calls so that they are in
the same order as the layout of the regions in memory; this makes no
functional difference, but it is less confusing to read.
BUG=b:210727578
TEST=Boot crosvm on trogdor64
Change-Id: I1238e5b1d412e41d0b4b9be5b93b59fec6598734
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3373451
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Rather than calling get_high_mmio_base_size() twice, once in the Arch
create_system_allocator() callback and once in build_vm(), it would be
cleaner to retrieve the MMIO regions from the existing system allocator.
Add a couple of helper functions to AddressAllocator so we can get the
original region back.
This also helps in the next patch, which will pass additional
information to get_high_mmio_base_size() that is messy to calculate
twice.
BUG=b:210727578
TEST=Boot crosvm on trogdor64
Change-Id: Ia5c7d7c7ff7edb406a9b4af482b277204f865474
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3373450
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add a function that returns the size of guest physical addresses. This
wraps KVM_CAP_ARM_VM_IPA_SIZE on aarch64 and CPUID to query host
physical address size on x86_64. This replaces the phy_max_address_bits
function from x86_64, and all callers are migrated to use the new Vm
function instead.
BUG=b:210727578
TEST=check on trogdor64 with debug prints
Change-Id: I3107fe6357fcf166b7ad0e2a7c55919705da3b0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3364971
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Andrew Walbran <qwandor@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@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>
Now that users of crosvm-direct have been adjusted to request extended
status from crosvm we no longer need to have this default.
BUG=b:209945145
TEST=./tools/presubmit
Change-Id: I15d9690979d77902329872ef9644a3279d653415
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3373480
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
The dev-rust/p9 ebuild passes the OWNERS file to fuzzer_install, so we
can't remove it entirely.
BUG=None
TEST=USE='asan fuzzer' emerge-amd64-generic dev-rust/p9
Change-Id: I34c4cdf505a64a73dc7d213dce0eb58de208cc1e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3373452
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The netlink data end boundary should be actually set by msg_len. The
previous calculation of data_end and its usage was probably confused with
data size.
This bug prevented access to the entire netlink's message data.
BUG=b:197247746
TEST=Build and print the `data` when netlink message arrives.
Change-Id: I601bcfee9132649f48f774e23426281ba1e88fde
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3375544
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The hdr_len was actually keeping length of the netlink message including
header (nlmsg) which was misleading. Rename it to msg_len which is more
accurate.
BUG=b:197247746
TEST=Build with 'USE=crosvm-direct emerge-${BOARD} crosvm'
Change-Id: Id4adcd038d41960eeeb8bda3623c8b3b129ef9df
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3375543
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
android13-5.10 will use this value to avoid conflicts with any other
flags introduced in upstream Linux before the pKVM ABI is upstreamed.
BUG=b:209794844
TEST=tools/dev_container tools/run_tests
Change-Id: Idee7c095ea5350baf2c38ab9190d4cdb46efbf25
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3372683
Auto-Submit: Andrew Walbran <qwandor@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
When sandbox is enabled, forking a process for hotplug device
is failure, the error message is:
Failed to fork jail process: Attempt to call fork() while
multithreaded.
This means minijail couldn't fork a new process for added device
when vm has started, so disable sandbox for hotplug device.
BUG=b:185084350
TEST=Boot a guest and hotplug vfio pci device repeatedly
Change-Id: I2983399f41a44984a113c9846aff93fd978a02b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2955581
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
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>
This is what I do all the time manually, maybe this can be automated.
BUG=None
TEST=run it and observe.
Change-Id: Ia32790ca7dd0b8313ce05dcff28509b8a21d4f76
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3336823
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@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>
https://crrev.com/c/3330204 changed the block fuzzer to depend on
hypervisor but did not add the necessary reference to Cargo.toml. Add it
to fix the fuzzer build.
BUG=None
TEST=Build crosvm ebuild with USE=fuzzer
Fixes: 00f1c9fd46 ("Update to the latest pKVM ABI.")
Change-Id: Ic90c6bdd29f87af1c78093a970056467e9c4c36e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3364963
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
In ARCVM `genfs_contexts`, we have hard-coded rules with device node id for
network and virtio-gpu. In crosvm virtio devices creation, the
device node id is assigned by order, so introducing 2 virtio-snd devices
will shift id to id+2 for those devices created after virtio-snd.
This will break ARCVM-next boot.
Changes:
Move virtio-snd device creation after virtio GPU.
BUG=b:213249578, b:199001477
TEST=cargo build
Change-Id: I2fd6ee2c892ae65b0e41d7f42613714a31d7833f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3366166
Auto-Submit: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@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>
