CL crrev.com/c/3005194 introduced changes to the encoder to allow
dynamic framerate changes even when there are already resources queued
in the input or output queue. As a side effect the encoder is only
recreated if any parameters besides the framerate change.
Unfortunately the above checks assumes that changing the framerate will
never influence any of the other parameters, which isn't always
correct. The requested H.264 level is adjusted to conform to the
minimum requirements for the selected bitrate and framerate. We can't
dynamically adjust the H.264 level during encoding, but as long as we
don't have any resources queued yet we can recreate the encoder to make
sure the H.264 level is properly adjusted if required.
BUG=b:192623395,b:192419592,b:193947502
TEST=android.media.cts.MediaRecorderTest#testProfileAvcBaselineLevel1
Change-Id: Ie02e30a5b6fb82b9b62e88ae3ab75c8ef42f3844
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3037296
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This reverts commit c6554e9c7e.
Reason for revert:
`time tast run mycros arc.Boot.vm` will always halt at
```
Waiting for Android boot
Waiting for initial ARC process
```
till timeout.
Original change's description:
> virtqueue: Try to further reduce unnecessary interrupts
>
> Try to reduce unnecessary interrupts by updating `signalled_used` every
> time we check `used_event` rather than only when we actually write to
> the eventfd.
>
> This technique is lifted out of the vhost_add_used_n and vhost_notify
> methods in drivers/vhost/vhost.c in the kernel and the variable names
> are changed to more easily compare the two implmentations.
>
> This combined with the other notification suppression changes give a
> performance improvement of ~10% across all storage devices in the
> blogbench benchmark.
>
> BUG=none
> TEST=vm.Blogbench.{p9,block,virtiofs}
>
> Change-Id: I618767e4c36ecae607b7641e54a029c25583844d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026691
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
BUG=b:194452080
TEST=time tast run mycros arc.Boot.vm
Change-Id: Ib7511dec3e0df26be54616f20226ded598fc8a37
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3051292
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Since CL:2999451, libcras is using timerfd features from `cros_async`,
we need to add timerfd operations to the accepted list of
`cras_audio_device`'s seccomp policy files.
BUG=b:179757101
BUG=b:194452080
TEST=tast run ${DUT_IP} arc.Notification.vm
Change-Id: I74b33fa1e304fccc95b7326e04bedc32feff85f1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3047951
Auto-Submit: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Try to reduce unnecessary interrupts by updating `signalled_used` every
time we check `used_event` rather than only when we actually write to
the eventfd.
This technique is lifted out of the vhost_add_used_n and vhost_notify
methods in drivers/vhost/vhost.c in the kernel and the variable names
are changed to more easily compare the two implmentations.
This combined with the other notification suppression changes give a
performance improvement of ~10% across all storage devices in the
blogbench benchmark.
BUG=none
TEST=vm.Blogbench.{p9,block,virtiofs}
Change-Id: I618767e4c36ecae607b7641e54a029c25583844d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026691
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Now that the get and set methods have the proper memory barriers it
should be safe to re-enable this.
BUG=none
TEST=crostini.Basic.buster_stable; reboot arcvm in a loop for 75
iterations without observing a hang
Change-Id: I03271d838e31ad091536163359836bead7e00178
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026690
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit e470ef9933.
Reason for revert: possibly breaks critical test, in turn CQ.
Original change's description:
> devices: irqchip: add need_halted function
>
> This allows irqchip implementations to specify whether they need to be
> notified via the halted() function when the vCPU encounters a HLT
> instruction.
>
> All of the current in-tree irqchip implementations do nothing on
> halted(), so this will always return false for now, but a fully
> userspace irqchip would need these notifications.
>
> Querying this function will allow the hypervisor code to determine
> whether disabling VM exits on HLT instructions is allowed.
>
> BUG=b:181106085
> TEST=test_all
>
> Change-Id: I433fe208d125dcd14e7100ce5aff37474b423a83
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2937304
> Reviewed-by: Colin Downs-Razouk <colindr@google.com>
> Reviewed-by: Zach Reizner <zachr@chromium.org>
> Tested-by: kokoro <noreply+kokoro@google.com>
> Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Bug: b:181106085
BUG=b:194452080
Change-Id: I755fc732e79a56f0306819e23ba9bd6c840dc927
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3045583
Commit-Queue: Leo Lai <cylai@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leo Lai <cylai@google.com>
Auto-Submit: Leo Lai <cylai@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
At present, libraries which use glibc to dynamically load
shared libraries do not have fstafs in their seccomp policies.
A change in glibc will force all systems which load shared
libraries to call the fstatfs or fstatfs64 syscall.
Without the call, crosvm will not start when running
crostini/android tests.
BUG=chromium:1182687
TEST=CQ of https://crrev.com/c/2910526
Change-Id: I10abb8866474c2fe0398a17a80069cf2b0629493
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3011355
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jordan R Abrahams <ajordanr@google.com>
The devices to be notified on resume are unrelated to the functionality
of Bus, which is looking up devices in an address space. Additionally,
each Bus instance had its own list of devices to notify, although in
practice, only the one in the I/O bus was used.
Move the resume_notify_devices list into RunnableLinuxVm instead.
BUG=None
TEST=Boot Crostini on x86 and arm
Change-Id: I72c629c6d6589c4a9350831c8a076c5c0c9f9aeb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3043489
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Rather than generating a random temporary file name for each plugin
generated by the test, just use a counter to ensure uniqueness.
This was the only remaining rand_ish user, so this change will allow the
removal of rand_ish.
BUG=None
TEST=cargo test --features=plugin
Change-Id: I8d42da97870db54a850f686826ca107255b8c3ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3017608
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
This allows irqchip implementations to specify whether they need to be
notified via the halted() function when the vCPU encounters a HLT
instruction.
All of the current in-tree irqchip implementations do nothing on
halted(), so this will always return false for now, but a fully
userspace irqchip would need these notifications.
Querying this function will allow the hypervisor code to determine
whether disabling VM exits on HLT instructions is allowed.
BUG=b:181106085
TEST=test_all
Change-Id: I433fe208d125dcd14e7100ce5aff37474b423a83
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2937304
Reviewed-by: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This should reduce the number of interrupts generated by the device as
well as the number of vm exits triggered by the guest for notifying the
device.
BUG=none
TEST=crostini.*; reboot arcvm in a loop for 30 iterations without
observing a hang
Change-Id: Iea4a59092ba6306de9eecbb7722d0ae356183272
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026689
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
It took me a while to realize the side effects making cargo fail.
BUG=None
TEST=read it.
Change-Id: I55db0e267452f865985d36d75c91a2314d117b06
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026652
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Compiling different binaries with different sets of features means that
we also end up recompiling a bunch of dependencies every time. Instead
just make the dependencies a superset of all crates/features needed by
all devices.
BUG=b:179755651
TEST=cargo test
Cq-Depend: chromium:3009693
Change-Id: Ic8faf2cbabd7b55b87d501639aee56ba5063de06
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2987592
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
p{read,write} cannot be used on sockets even if the file offset is 0.
Make the file offset optional and fall back to regular read/write when
it is not set.
BUG=none
TEST=cargo test
Change-Id: Iff938aabe613b6164782714cfac94743d64f551a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3033233
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Woody Chow <woodychow@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
In order to enable the VIRTIO_RING_F_EVENT_IDX feature, devices need to
keep processing the queue until it is empty as the guest may not send
any more notifications until the device has processed all pending
messages.
Change the process_queue method to process all messages in the queue.
BUG=none
TEST=????
Change-Id: I7df56111ad99bc7511c685ecafc051aef077b34e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026688
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When the VIRTIO_RING_F_EVENT_IDX feature is enabled we will
automatically update avail_event when a descriptor from the queue is
popped. Having update_int_required set this to a different value means
that it would keep going back and forth.
BUG=none
TEST=crostini.Basic.buster_stable
Change-Id: I9098259c306cf19c034656169ee0e70ad69d1c64
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026687
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Have all devices trigger interrupts via the Queue rather than directly.
This way we can skip sending the interrupt entirely when notification
suppression features have been negotiated with the guest kernel.
BUG=none
TEST=crostini.Basic.buster_stable
Change-Id: Ica6f978127aa648fd983f641518940d7a857916f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026686
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Supply the OS with basic PCI hostbridge information (PIO region, MMIO
region, etc) using Device (_SB.PCI0) in DSDT. Without this info the
Linux kernel behaves erroneously in iova_reserve_pci_windows().
Output from the Linux kernel, w/o _SB.PCI0:
pci_bus 0000:00: root bus resource [mem 0x00000000-0x7fffffffff]
Since DSDT contains PCI hostbridge information, ACPI is always required.
Use "acpi=noirq" in cmdline when DSDT/MADT is not provided by the user.
The Linux kernel refers to PCI configuration space for interrupt
routing.
BUG=b:181736020
TEST=boot Linux kernel and check dmesg
Change-Id: Id328a958fb770e087788e71fe480839eab4f40c7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2846422
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This is needed because virtio IOMMU may not allow writes to mapped
memory if VIRTIO_IOMMU_MAP_F_WRITE flag is not set in driver MAP
request.
BUG=b:181736020
TEST=--vfio=/sys/bus/pci/devices/0000:00:14.0,iommu=on
Change-Id: I2c101410594782f1b66b3f6ae527d4a7621b7496
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757279
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
In VT-d, the IOMMU hardware can translate guest physical address that
is no more than MGAW (Maximum Guest Address Width) which is reported
from the VT-d Capability register.
We pass this information to the guest IOMMU front driver so that it
can allocate appropriate IOVA.
VT-d indicates that "implementations must support MGAW at least equal
to the physical addressability (host address width) of the platform".
Thus we take the Physical Address Bits that is reported by
CPUID.80000008H as the minimum MGAW.
BUG=b:181736020
TEST=--vfio=/sys/bus/pci/devices/0000:00:14.0,iommu=on
Change-Id: I26a421ea2e7dd893d413d63ab313721cfdf0b5c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757278
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
This change allows us to redirect in/out streams for a vhost user
console device to any file. This means we can assign individual PTYs for
input/output redirection to the host VM.
Example command:
vhost-user-console-device --socket $SOCKET --output-file $OUT_FILE \
--input-file /dev/pts/$NUM
You can `echo <message> > /dev/pts/$NUM` to send input signals to the
VM, and `tail -f $OUT_FILE` to monitor the output in real time as it is
written to a file.
BUG=b:192517623
TEST=run vhost-user-console-device with --output-file and --input-file
Change-Id: Iee0929d63d39848f2626c17e440d6d9368ae2d0f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026359
Auto-Submit: Morg <morg@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Morg <morg@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
A completed fence callback is set in Rutabaga. When the callback
is executed, the descriptor associated with the fence is immediately
marked as used and the control queue is signalled.
As of now, the callback is still called in the main worker thread
when poll_fence() is executed, but once we enable the async callback
feature in virglrenderer, the callback might be called from another
thread. This is the reason everything is protected with mutexes.
The completed_fences hash map keeps track of the latest completed
fence for each context to avoid any race condition.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Change-Id: I6f3f55d21b7f4722721bdc2b16da1b39bae4ff7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2845984
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Add a spawn_blocking() method to the Executor so that users don't need
to manually create a BlockingPool every time they need to do some
blocking work.
BUG=b:179755651
TEST=cargo test
Change-Id: I70d111d98a4c51af4bc8ed8181a4b102bf3c2ffa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2987586
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
These values are either written by the device and read by the guest or
vice versa. Either way, since these could happen simultaneously on
separate cores we need fences to prevent the CPU from re-ordering loads
and stores.
"get" methods use acquire-load semantics while "set" methods use
release-store semantics. This also matches what we were already doing
for "get_avail_index" and "set_used_index".
With this it should be possible to re-enable the check for
VIRTIO_AVAIL_F_NO_INTERRUPT but we'll do that in a separate change since
we need these changes no matter what.
BUG=none
TEST=crostini.Basic.buster_stable
Change-Id: I2d52c92fbd7ab0fe6d64693d60f46d0dec4b4cb5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3026685
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Currently changing the framerate during video encoding will always fail
once resources are queued on the input or output queue. This CL makes
adaptations to the crosvm encoder to fix dynamic framerate changes.
To support dynamic parameter changes the crosvm encoder will now
properly check whether values actually changed, and only report an
error if we're trying to change static parameters during encoding (such
as the output format). As a side effect this greatly reduces the amount
of times the Chrome encoder is recreated; parameters are configured
one-by-one through virtio and each parameter change requires us to
initialize an encoder, as we only know the coded size after the
initialized encoder calls the RequireBitstreamBuffers() callback.
BUG=b:192623395,b:192419592
TEST=android.media.gts.RtcVideoCodecTest#testDynamicFramerateChangeVp8
Change-Id: I20e60013dbdf9f4b139c795f503c6a08a7d3e6e9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3005194
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This fixes:
* version mismatches in Cargo.lock
* style issues
* implementations of Into that should be From
* deprecated protobuf APIs
It also adds RUST_BACKTRACE=1 to the kokoro tests.
BUG=None
TEST=./bin/preupload-clippy
Change-Id: I8e9157c903f2080a5fdcc4d3e4ed72fbad41c64f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3024427
Auto-Submit: Allen Webb <allenwebb@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Allen Webb <allenwebb@google.com>
Add vhost-user device of mac80211_hwsim that connects to
the unix socket of vhost server for mac80211_hwsim for
emulating Wifi device at crosvm.
Add cmdline flag --vhost-user-mac80211-hwsim for
specifying unix socket path to connect.
BUG=b:182577273
TEST=At Android's source tree,
lunch aosp_cf_x86_64_phone-userdebug &&
m PRODUCT_ENFORCE_MAC80211_HWSIM=true &&
launch_cvd \
--vhost-user-mac80211-hwsim=${VHOST_SOCKET_PATH}
Check AndroidWifi appears at wifi connection settings.
Change-Id: I33e5d8fed59c84d3848bfe24d935ce973d758e12
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3020848
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: JaeMan Park <jaeman@google.com>
Kernels before 5.10 had known bugs in the io_uring implementation.
Don't use io_uring when we detect this. Also skip all the io_uring
tests in this case.
BUG=none
TEST=cargo test
Change-Id: I5fd6203ad25a6fb85ff28f1a6ddb0181f836ad89
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3006309
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Woody Chow <woodychow@google.com>
Make sure that file descriptors associated with GuestMemory are
inherited by each child process. Not inheriting them means that
GuestMemory thinks it owns a bunch of fds when it actually doesn't and
closing them in the child process would either lead to EBADF errors or
closing some unrelated fd.
BUG=none
TEST=CQ
Change-Id: I5475f3f9cc24cc62522066b8535693f95327cd92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3023805
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Move the call to enable_protected_vm past the PVTIME memory region
allocation introduced by 895c90c5f2 ("aarch64: Implement
ARM_VCPU_PVTIME for "stolen time" accounting"). As such allocation is
prohibited once protected VM mode has been enabled (Kernel returns
EPERM), which currently results in crosvm failing when started with
--protected-vm.
BUG=b:193231584
TEST=crosvm --protected-vm on a kernel with KVM_CAP_ARM_PROTECTED_VM
Change-Id: I2a97d3ff64ed59dd6679e51951c79e27bf290d5e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3021126
Reviewed-by: Andrew Walbran <qwandor@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Pierre-Clément Tosi <ptosi@google.com>
BlockingPool provides a dedicated thread pool for running blocking
operations. This is useful when an async task wants to do some
CPU-intensive computation, run some IO operation that cannot be
performed asynchronously, or to call a blocking API in a dependency that
doesn't have an asynchronous variant.
BUG=b:179755651
TEST=cargo test
Change-Id: I389fc504f380d66325739d2d6b7afe58e024194d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2987585
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This change is a refactoring of the initial Console backend
implementation to make use of already-existing serial console
initialization code. It allows us to leverage from already-existing code
for alternative input/output files.
BUG=b:192517623
TEST=run crosvm with vhost-user-console and no changes are detected
Change-Id: I433cad1fac8f415173aee06b8ad1c96eb8f6690b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3023804
Commit-Queue: Morg <morg@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Auto-Submit: Morg <morg@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
- Adds the ability to start/stop background thread on demand
- Changes the way audio data is injected to not assume how the data is
kept by users of the api
- Adds new functions for jacks and chmaps
- Rename constants to match the name used in the virtio-snd spec
BUG=b:174713663
Change-Id: Ie0fe20747a26122258cb63bac09ec0347f13ecc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983388
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Previous code assumed there's a single InterfaceDescriptor per
ConfigDescriptor's bNumInterfaces. Which means they can only have a
single alternative setting. However that isn't always the case.
For example Logitech C930E webcam has the following configuration:
Device Descriptor:
bNumConfigurations 1
Configuration Descriptor:
bNumInterfaces 4
Interface Descriptor:
bInterfaceNumber 0
bAlternateSetting 0
Interface Descriptor:
bInterfaceNumber 1
bAlternateSetting 0
Interface Descriptor:
bInterfaceNumber 1
bAlternateSetting 1
<skipped>
Interface Descriptor:
bInterfaceNumber 1
bAlternateSetting 11
Interface Descriptor:
bInterfaceNumber 2
bAlternateSetting 0
Interface Descriptor:
bInterfaceNumber 3
bAlternateSetting 0
Interface Descriptor:
bInterfaceNumber 3
bAlternateSetting 1
<skipped>
Trying to attach a device where this isn't true led to errors like this:
[transfer_ring_controller.rs:50] failed to send transfer to backend
Tested by attaching Logitech C930E webcam to VM and
./ci/builder 'cargo test -p usb_util'
Change-Id: Iab671bff26558838becbbafe0a43ed6dc220306c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983386
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Leonid Lobachev <leonidl@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
page_size_mask in IOMMU device configuration contains the bitmask of all
page sizes that can be mapped. It's good to get this information from host
VFIO/IOMMU driver, so that the guest is able to issue DMA mapping requests
with page size as large as possible to reduce the number of DMA map requests.
BUG=b:181736020
TEST=--vfio=/sys/bus/pci/devices/0000:00:14.0,iommu=on
Change-Id: I4c003473a48688cbdde0ff162dd0b414926d5c88
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757277
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
By default virtio-IOMMU is disabled. It can be enabled per pass-through
device. Sample command lines:
default: virtio IOMMU disabled on pass-through device:
--vfio=/sys/bus/pci/devices/0000:00:02.0
Explicitly disable virtio IOMMU:
--vfio=/sys/bus/pci/devices/0000:00:02.0,iommu=off
Enable virtio IOMMU on the desired pass-through device:
--vfio=/sys/bus/pci/devices/0000:00:02.0,iommu=on
BUG=b:181736020
TEST=passthru one device with iommu=on
TEST=passthru two devices with iommu=on from different VFIO group
TEST=passthru two devices with iommu=on from same VFIO group
TEST=passthru one device with iommu=on and another device with iommu=off
Change-Id: Id74d2210f774a90ba5e83671e76e061cb8fec758
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757276
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
This is to backport virtio IOMMU backend driver from Cloud-hypervisor,
which emulates an IOMMU device to manage DMA from one or more endpoints
in the guest.
Some differences from the Cloud-hypervisor implementation:
- Simplified the mapping between IOMMU driver and Vfio container
- This port supports multiple endpoints attach to same IOMMU domain.
BUG=b:181736020
TEST=bin/clippy, functional tests specified in the patch
"iommu: enable virtio IOMMU driver"
Change-Id: I3db3b46a72e82908459e91a4e6852a335c606db1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2846421
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
In preparation for virtio IOMMU support, implement global variables
IOMMU_CONTAINERS and NO_IOMMU_CONTAINER to hold the VFIO containers
for VFIO devices with or without IOMMu enabled respectively.
Also implement vfio_get_container()help create VFIO container based
on the more complicated policies.
- all VFIO devices without attaching to virtio IOMMU devices share
one VFIO container.
- for IOMMU enabled devices, one VFIO container manages all devices
under one VFIO group.
- we don't support multiple IOMMU groups set to one VFIO container.
Currently don't see an user case for this.
BUG=b:181736020
TEST=unit tests.
Change-Id: I44d792cbc8ca9696c1da54c571aad1b94c7f665d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2976054
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
One KVM_DEV_TYPE_VFIO instance may be created per VM. Currently this
device is created from VfioContainer::init(), which makes it not able
to create multiple vfio container.
This patch creates the KVM_DEV_TYPE_VFIO virtual device before creating
any VfioContainer or VfioDevice instances, and passes it into the
VfioDevice constructor where it's actually used. In this way, it's
possible to create multiple VFIO containers
BUG=b:181736020
TEST=passthru multiple devices and create more than one VFIO containers
Change-Id: I4b4e4941363efa91f2217af385f4f00eadd041c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2976053
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
