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>
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>
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>
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>
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>
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>
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>
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>
Long-term libvda will be replaced with an implementation that can
function outside of ChromeOS.
In the meantime thes allows crosvm to be built externally and pass
clippy with all features enabled.
BUG=b:191507399
TEST=Tests in crosvm and cros_sdk both pass:
$ ./test_all
$ cros_run_unit_tests --package=crosvm
Cq-Depend: chromium:2989315, chromium:2986403
Change-Id: Ic37bda4426d69d16cb4bc0d7ba6f81052f6f2f59
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983505
Tested-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Add a new vhost-user device binary implementation.
Example command to launch the device:
vhost-user-console-device --socket test
BUG=b:179755825
TEST=run crosvm with vhost-user-console and the console comes up
Change-Id: I4bb06e058523b73cb01fbe993e0fe7f9e4ee6423
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2951187
Auto-Submit: Morg <morg@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Morg <morg@chromium.org>
This adds a vhost-user console to the vmm, which will be enabled by
`--vhost-user-console <socket path>` option.
BUG=b:179755825
TEST=launch crosvm with --vhost-user-console and connection happens
Change-Id: I6339c6cde3a221fd3e6a1652474e17344c73d6d3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2814058
Auto-Submit: Morg <morg@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Morg <morg@chromium.org>
The output buffers must all have the same pixel format, therefore it
doesn't make sense to pass it with each buffer we import. Instead, pass
it alongside the number of output buffers (before any buffer is
imported) and let the backend remember it.
BUG=b:161774071
BUG=b:169295147
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I1890ad24f9874ed3c674a7bdf7d4be303ba24e92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983094
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Methods that mutate the backend should take a mutable reference to self.
This problem was not apparent with the VDA backend since libvda's
methods themselves are not mutable, but this will cause issues with
backends that include more of their own data.
BUG=b:161774071
BUG=b:169295147
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I61cc64b6cbb9f4d1633c6a0acc188bbfc8dd0c54
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983093
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This is useful for e.g. unit tests.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: Ica409926c9da6c788a60134fa3f609db97f4aaa4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983092
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
We are using similar structures for describing the planes of a frame in
the decoder and encoder. Consolidate them into a single structure
accessible from the shared format module.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I289c896e022cbb0952a1f2be626b3f8a6caaf13e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983091
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
The interface to return the event pipe for a backend currently requires
a &File to be returned, which is not very appropriate since the file
only serves as a proxy to the pipe's file descriptor.
Although libvda uses this structure to return its event pipe, this won't
be the case for all backends, so change the interface to return a
non-owned Descriptor, which is more generic and suitable to the task.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I73dc66ba59e023a77d7b8e0efe533ec7805cf441
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983090
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Cuttlefish's streaming server, which acts as a Wayland compositor
in order to receive display framebuffers from Crosvm, needs some
mechanism to tell which Wayland surface corresponds to which display
(a "display" is a "scanout" in virtio-gpu terminology).
Wayland object ids can not be directly used for this as all Wayland
objects share a single global id space (so the first created Wayland
wl_surface surface object may have id = 15).
Previously, the case of unchanging displays was handled by enforcing
the creation order of surfaces within Crosvm so that Cuttlefish's
streaming server (which is a Wayland compositor) could assume the
creation order corresponded to the display order. However, this still
experienced issues (b:186580833) when surfaces were destroyed and
later recreated when handling `set_scanout(..., resource_id = 0)`
commands.
There is also an ongoing effort to support adding and removing
displays at runtime in (see aosp/1671968) which experiences the
same issue. When surfaces are arbitrarily created and destroyed,
Cuttlefish's streaming server has no way to determine which Wayland
surface corresponds to which display.
To solve all of this, this change introduces an extension to allow
Wayland clients (Crosvm) to attach additional metadata (scanout_id)
to Wayland objects (surfaces) so that Wayland compositors (Cuttlefish's
streaming server) can exactly determine which surfaces correspond
to which displays. I will attempt to upstream this protocol (tracked
in b:191901112).
BUG=b:188904670
BUG=b:187351899
BUG=b:191901112
TEST=launch Cuttlefish with single display
TEST=launch Cuttlefish with multiple displays
TEST=launch Cuttlefish and hotplug some displays
Change-Id: I2aa4b714a49e4d85b6a3c705ba0d5bc1720b838e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2909903
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
The new cras_backend to be implemented will use these functions
BUG=b:179757101
TEST=cargo test
Change-Id: Ie1777d79a16303e562740b2e02f6b509fab4ef92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2993704
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Commit-Queue: Woody Chow <woodychow@google.com>
Commit-Queue: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Updates virtio-gpu frontend to track multiple
scanouts and the resources set for those scanouts.
Adds a --gpu-display command line arg to avoid having
to create a very complicated --gpu string.
BUG=b:173523402
TEST=launch Cuttlefish w/ multiple displays
TEST=(see change series at aosp/1652814)
Change-Id: I73174c11f35f865b8b67ae77d8169d6812f85535
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2836265
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
use_output_buffer() can fail, in which case we won't have processed any
buffer. Increase our ID counter only if we are confident a buffer with
the assigned ID will eventually be delivered.
BUG=b:161774071
TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
Change-Id: I37ad68059854182795ff631b3816614058444900
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2983088
Tested-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Staessens <dstaessens@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
It allows Rutabaga library users to set a fence callback on the
component builder or while creating a context. The handler is
called when a fence is signaled as completed and could
be executed from another thread.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Change-Id: Ia9176bf2f0822a0076bed6a7a09e709b426aa620
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2845982
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
The vhost user block device can be started as follows:
```
cargo run --features=block --bin vhost-user-block-device -- \
--file vhost_test.img --socket /tmp/vhost_user_blk.socket
```
Or a read only disk:
```
cargo run --features=block --bin vhost-user-block-device -- \
--file vhost_test.img:read-only --socket /tmp/vhost_user_blk.socket
```
And tested with a crosvm instance as follows:
```
cargo run -- run --disable-sandbox --rwroot debian.ext4 \
-p "console=hvc0 root=/dev/vda rw" \
--vhost-user-blk /tmp/vhost_user_blk.socket bzImage
```
The vhost-user-block device will appear as /dev/vdb.
BUG=b:179755342
Change-Id: Ie8c10dad8978e0f4a381e06576239df1e8174db5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2948103
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
These functions will be used from the `vhost_user_devices` code to run
vhost-user block.
Change-Id: I8351a9b0ced1e36a0543096c59560bbd14dba06a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2948102
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Added preliminary version of keyboard and pointing device routine
for wayland implementation. The pointing input is wired as a multi
touch device. Due to the fact that wayland client is callback based,
all the necessary incoming events are serialized and stashed in the
temp circular buffer and then processed afterwards from the main event
loop.
Known issues:
1. Mouse input can't be properly wired inside the guest as a mouse
device without pointer locking, but this is not what we want. The
approach emulates it as a multitouch device, but, of course, it
implies limitations in functionality. Limitations include cursor
in the VM that doesn't move in unison with the host cursor.
2. I kept the mouse cursor surface since it's not decided yet which
approach for handling pointing input device will be used (see #1).
Removing the mouse surface in the guest would remove the lagging
guest cursor. The alternatives to the multi-touch device are:
"- Relative mice (e.g. a typical PC mouse). These are relative
devices, meaning they send deltas from the current cursor
position. Some apps like games rely on these events.
- Touchscreens (multitouch, single touch). These are absolute
devices, and are much easier to implement seamless guest/host
input for.
- Touchpads (these are absolute devices). I'm not sure these are
really compelling for any use case." -nkgold@
3. This code is for POC purpose only, so there are still lot of minor
issues and negligence in it.
Looking forward for your comments and proposals.
BUG=b:177939148
TEST=crosvm $ARGS \
--display-window-keyboard \
--display-window-mouse \
--gpu=3d,glx=false,egl=true \
--wayland-sock=/run/user/1000/wayland-0 \
$OTHER_ARGS
Change-Id: If4a9b73b8da4e0cc52fa619bbd6e5588ccdb7874
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2688439
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Although the current crosvm won't change call fd once it's set, the
vhost-user allows it and QEMU does so.
So, we wrap CallEvent with `Arc<Mutex<...>>` so that we can replace the
fd later.
BUG=b:190450677
TEST=run with QEMU using vhost-user net device
Change-Id: I16cbcd843e370aeaf6b28c8a520b3bfa4a35286b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2950027
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
The features bit manipulation was already duplicated and will be needed
again in the vhost_user implementation.
Change-Id: I8a75341053feac8c222c2d959370aa9f32a82258
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2948101
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
There is a desire for Wayland and possibly other display backends to
reasonably handle input. Move the event device logic inside the X11
backend up to the common layer to prevent duplication.
The common layer also keeps track of surfaces and external memory
objects to make this easier. The GpuDisplaySurface/GpuDisplayMemory
traits are introduced in case the common layer needs to perform
compositor specific operation.
BUG=b:173630595
TEST=compile and run with X11
Change-Id: Ied060a7cc216ac6c084030aad1fc839c022a3395
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2852523
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
It is inherently racy to wait on a Condvar without first checking if the
condition is already satisfied. Additionally, Condvar::wait can
spuriously return early even when the condition is not satisfied so it
is necessary to check it in a loop.
BUG=b:190444698
TEST=cargo test
Change-Id: If7703c6e8b9015df3c463147f3ad2a1c10c3a7ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2944323
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The resource bridge is only used by 2 methods of Device, so it makes
little sense to have worker maintain it and pass it around. Make it a
member of Device instead.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: I5d305177b5fa6d86ee49d404a0fd65ba573578a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932301
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Chih-Yu Huang <akahuang@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
This removes the need to pass the descriptor map as an argument of all
Worker's methods.
BUG=b:161774071
TEST=GTS DashTest passes on hatch-arc-r.
Change-Id: Ide8d1a858bb09f1098a38c49643fdf365ae7aec1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2932300
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
