Add a convertion for the VP8 VA profile, otherwise the profile will be
skipped when the Capabilities are built and VP8 will be unsupported.
BUG=b:214478588
TEST="Decoder reports VP8 as supported (e.g.: if using GStreamer,
gst-inspect-1.0 video4linux2 lists a VP8 decoder)"
Change-Id: I6af62b475d840f309c3bdc7cc05e7722149c9b3b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3907527
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Do not drain the ready queue if we have not been provided buffers by
CrosVM.
The previous implementation would attempt to drain as soon as a picture
was ready to be outputted, but this does not account for the fact that
there is a window of time between ProvidePictureBuffers being emitted
and set_output_parameters() being called, as the guest needs to process
the request.
This meant that ready frames would be dequeued, but the call to
output_picture would return Err, effectively dropping the frames before
they could be outputted.
Simply return early if OutputQueueState != OutputQueueState::Decoding,
leaving the queue as is.
BUG=b:214478588
TEST="Decoding test-25fps.h264 yields exactly 250 frames."
Change-Id: I6042f4556933d4b59a54c6ca986510356a040e18
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3903094
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
The reset implementation for the VAAPI backend was wrong for a couple of
reasons.
It would create a new session, thereby invalidating the eventfd file
descriptor passed to the WaitContext. This meant that events would not
get signalled from that point on.
Also it would recreate the codec instance, but the right thing to do
here is to flush, which resets the internal state without needlessly
invalidating the allocations already made.
The above is also the same logic done by the ffmpeg decoder, which calls
avcodec_flush_buffers instead of recreating the AVCodecContext.
The previous implementation would also not clear the submit and ready
queues.
Not clearing the submit queue meant we could not return the buffers to
crosvm, which is against the contract for reset(). This is because this
queue keeps a reference to GuestResourceHandle.
Not clearing the ready queue meant that we would return stale buffers
once/if decoding resumed.
Lastly, it would reset the state of the output queue to
AwaitingOutputBuffers, but we can resume decoding with no new buffers
provided, so this is incorrect.
In particular, this change eliminates the following error reported by
the virtio video kernel driver:
virtio-video virtio-video.5: timed out waiting for queue clear
And also the related CrosVM virtio video worker error: returning async
error response: invalid operation
As the ResetCompleted event is correctly signalled now.
BUG=b:214478588
TEST="Decoding in the guest does not cause these two warnings to be
emitted: virtio-video virtio-video.5: timed out waiting for queue clear
and returning async error response: invalid operation right after that"
Change-Id: I0ed2fc59819875fb3cc4462d401811f3126ab686
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3903093
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Introduce try_make_progress() as a way to enforce the following
invariant between the submit and ready queues: the ready queue must
always be drained first.
This is to avoid deadlocks: draining the submit queue will fail if the
ready queue is full enough, since this prevents the deallocation of the
VASurfaces embedded in the handles stored in the ready queue. This
means that no progress gets done.
While we are at it, make sure to call it in places where we were only
erroneously draining the submit queue (which again, means that no
progress could be made)
BUG=b:214478588
TEST="The decoder does not randomly stalls if the guest app is too slow
to retrieve frames in the ready queue"
Change-Id: I9ea34089b7df4417272cdc775d42422b865a993c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3901198
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
We are always done with the input buffer even if no frames are generated
by the decoder. Reflect this by always releasing the buffer after a call
to self.codec.decode()
While we are at it, note that it's the resource_id that has to be passed
to NotifyEndOfBitstreamBuffer.
BUG=b:214478588
TEST="Guest does not complain about unknown resource_ids when processing
NotifyEndOfBitstreamBuffer"
Change-Id: I61c0d2f0e7ea6a4907e853bb2f005bb421447042
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3901197
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The current code will add an input format even though it might not be
able to be decoded to NV12. This will be fixed in a later patch, but for
now just drop these formats instead.
BUG=b:214478588
TEST=cargo test -p devices --features=video-decoder,vaapi virtio::video::decoder::backend::vaapi::tests::test_get_capabilities -- --include-ignored
Change-Id: I89e7261fdc935207f1fcb11d18e7701cdaf54ba9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3901274
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
The max width and height from the coded side are the best approximation
for the max width and height of the raw side if the actual values are
not available in VA-API.
In particular, it's extremely unlikely to have 1x1 as acceptable values
for max_width and max_height.
BUG=b:214478588
TEST=cargo test -p devices --features=video-decoder,vaapi virtio::video::decoder::backend::vaapi::tests::test_get_capabilities -- --include-ignored
Change-Id: I6d9830b4da69f29f5e2e11c3fa688db4a7007726
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3901273
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The raw capabilities should not depend on the value for rt_format.
Both in the Intel and Mesa implementations it can be seen that setting
VAConfigAttribRTFormat as a parameter to vaCreateConfig only serves as a
way to validate that the to-be-generated config supports it.
This means that the Intel implementation will only use it in
CheckAttribList, while Mesa will AND it with a precomputed bitmask of
supported values in vaCreateConfig.
Thus, creating one RawCaps instance per value of RT_FORMAT only serves
to create needless duplication.
Not only that, but it frequently makes the call to QUERY_CAPABILITIES
fail, as the resulting structures become too large to fit into the 1024
byte buffer.
Remove all traces of VA_RT_FORMAT_* from this code path. While we are at
it, note that the libva crate API for vaQuerySurfaceAttribute changed to
reflect that this call can return more than one attribute at once.
This is particularly important for VASurfaceAttribPixelFormat, as one
value per supported fourcc is returned. We now properly return one
instance of RawCaps per VA_FOURCC supported.
Also reflect that Surface attributes can be defined more than once
This is particularly the case with VASurfaceAttribPixelFormat, where the
driver will define one attrib per pixel format supported.
This can be seen in the Intel driver, for example, in
MediaLibvaCaps::QuerySurfaceAttributes.
The previous code assumed that a given attribute could only be defined
once, and thus used find(). It was refactored to use filter() instead.
The name of the method was changed to reflect that it can now return
more than one attribute per call. The return type was changed to Vec for
the same reason.
BUG=b:214478588
TEST="cargo test --package devices --lib --features video-decoder --features vaapi -- virtio::video::decoder::backend::vaapi::tests::test_get_capabilities --include-ignored"
Change-Id: I914376beb026e30b2a52ca8f7d01c81e6a9a2775
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3946301
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Queue incoming requests so that they can be retried if the backend runs
out of resources.
Previously the VA-API backend would just refuse to decode if all
allocated surfaces were in use. Notably this can be the case if the
surfaces are kept in use by virtue of being in the ready queue. An
example of which could be seen whenever the guest would not retrieve the
decoded images as fast as the hardware decoder would produce them.
This issue can be worked around by keeping a queue of the decode
requests in the order they were submitted by the guest. The operation
can then be retried either on the next call to decode or when a new
output buffer becomes available, whatever comes first.
BUG=b:214478588
TEST="Decoding from the guest does not fail with
StatelessBackendError::OutOfResources"
Change-Id: I53b972f6520bdc704be6eaca14c5343391122914
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3875045
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Port the VAAPI backend to the new cros-codecs crate. This crate now
contains all codec related code and is independent from the rest of the
CrosVM code.
BUG=b:214478588
TEST="cargo test --package devices --lib --features video-decoder --features vaapi -- virtio::video::decoder::backend::vaapi::tests::test_get_capabilities --include-ignored"
Change-Id: Id207c53c0c4200e03ce8793d7c37cb5fbe808829
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3875044
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This change moves most ircchip tests into an integration test.
These tests rely on kvm, and if they do not - reuse much of the
test code from each other, so they need to move together.
Note: This removes the apic_timer test. The test has been disabled
for a while due to it's use of sleep in unit tests.
We cannot support it as an integration test either, since it combines
the sleep with a FakeClock. userspace.rs swaps the real clock for
FakeClock when compiled with cfg(test), but integration tests do not
compile with cfg(test), so we cannot use the FakeClock.
The biggest side-effect is faster execution as we can run all other 300+
tests in parallel and via user-space emulation, significantly cutting
down on the test times. It also allows those tests to run in a
podman container.
BUG=b:244620308
TEST=CQ
Change-Id: I1728a736d27e924daf228752711435885dacfa6a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3977111
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Other device parameters with a backend type use `backend` as field name,
so do the same for video devices. This is backward-compatible as the
backend field is implicit for the command-line.
BUG=b:255223604
TEST=cargo build --features "video-decoder,video-encoder,ffmpeg"
Change-Id: I5133080714d3292295468a2c7152a06fc669da1c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3974353
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
If crosvm's connection to the host compositor is suddenly broken
(e.g. from a compositor crash), a single POLLHUP is sent on the listened
file descriptor, but it is ignored. Then the VirtioGpu backend is
repeatedly awoken to handle display events, although there are none.
Since the compositor is lost and there is currently no path for
recovery, we can at least prevent runaway CPU usage by removing the
display from VirtioGpu's WaitContext. For VMs that can continue to
function without a guest display (headless crostini), this is
non-lethal. For VMs that require a display (ARCVM), other mechanisms
already exist for shutting down the VM under such unrecoverable
conditions.
BUG=b:250923109
TEST=Run Crostini and trigger a chrome crash; inspect virtio_gpu CPU
usage
Change-Id: I8b2261a093191dfe142697c4c4adc4e9ffab751a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3975942
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
The `root` and `rwroot` command-line parameters allow to specify a block
device for which the right parameters are passed to the kernel to mount
it as the root filesystem. This approach relies purely on the name of
the parameter given and won't allow us to pass a "root" flag to a
unified block device command-line option.
Address this by adding a "root" member to `DiskOption`. On top of
allowing us to specify the will to mount a particular device as root
through a flag, it also clarifies the code a bit as we deal with one
less unnamed tuple.
BUG=b:218223240
TEST=Guest Linux boots as expected with the `--rwroot` option.
Change-Id: I5d5eda1cc8b1fc2f08e798064fc0db3b17f000a3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3970363
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Only gfxstream is being actively used on Windows for now, so we
either use it or fall back to 2D rendering by default.
This CL also puts ModeVirglRenderer under the "virglrenderer"
feature flag, so that the arg parser would reject it when specified
by mistake.
BUG=b:254284360
TEST=presubmit
Change-Id: Ifa39e4a528acf1bd45a85e7327b3edded3a4e7d6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3971026
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Commit-Queue: Pujun Lun <lunpujun@google.com>
libvda is only available on ChromeOS, and being unable to link to it
with regular builds reduces our build coverage.
Add a "libvda-stub" feature that, if enabled, results in dummy C stubs
being build for all the exported libvda functions. This allows builds
with the "libvda" feature to pass, although of course the resulting
video device would immediately crash and thus should not be used.
BUG=b:244619291
TEST=`cargo build --features="video-decoder,video-encoder,libvda-stub"`
completes.
TEST=`cargo build --features="video-decoder,video-encoder,libvda"`
reports link errors against libvda.
TEST=`cargo build --features all-x86_64` builds libvda and completes
without error.
Change-Id: I9bb60f6caf670081d67c91275727f3888272d64b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3947844
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Add a vhost protocol feature flag for shared memory region support. This
is necessary to avoid sending the GET_SHARED_MEMORY_REGIONS message to
backends which don't support it.
BUG=b:252901073
TEST=crosvm device wl
Change-Id: I044926e982526c3c76063b5386cab0db72524707
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3951472
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Adds a new error code for when we fail to open a disk image. Also adds
an exit code we were missing upstream.
BUG=b:253348635
TEST=intentionally messed up the disk image path and verified we get
this error.
Change-Id: I197b4c5d80682dd1ee2a42d02df852276d204c17
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3961530
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Noah Gold <nkgold@google.com>
Fix shared memory support for vhost-user wl implementation. Handle
set_slave_req_fd being called before get_shared_memory_regions and make
sure the wl device only tries to get its shared memory mapper once.
BUG=None
TEST=crosvm device wl
Change-Id: I724712399bd6a9ffbffb22dd69d431f54df58282
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3965812
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Qualcomm has developed a wrapper program which uses CrosVM's libdevices
crate. Some Qualcomm products use 128 as virtio block queue size and
some of them use 256 depending on the memory constraints.
Number of virtqueues per device may also vary on different products.
This change lets virtio block new() function accept arguments that
specifies virt queue size and number of virt queues.
Qualcomm's wrapper program calls new() method with required number of
queues and queue size at runtime.
When they are not provided at runtime, they get their default values.
Change-Id: I71d8340e9a97009ae855cc0403d45f8c5c1cb55f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3965432
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Gunyah hypervisor supports virtio-mmio transport only in some
products on which CrosVM is also used. Qualcomm has developed
a wrapper program which uses CrosVM's libdevices crate.
Gunyah hypervisor has some optimizations for how virtio-mmio
register access are handled. Normally they are synchronous access -
meaning any access of virtio-mmio register by a guest will cause
a fault, which requires blocking the guest VCPU until the access
can be served by CrosVM running in a different VM. Since that could
induce long delays for guest (esp since the OS in which CrosVM is
hosted is considered untrusted), Gunyah hypervisor caches all
virtio-mmio registers in its address space.
Any read access is handled without requiring intervention from CrosVM.
Write access is handled asynchronously - i,e a write will cause
hypervisor to updates its copy of the register, unblock the guest vcpu
and simultaneously notify CrosVM about the update.
By the time CrosVM gets to notice the update, guest could have
progressed lot more.
This works reasonably well for many devices and registers.
One problem case is writes to VIRTIO_MMIO_INTERRUPT_ACK, which signals
the guest having seen an interrupt. CrosVM seems to rely on synchronous
handling of this register write. Any attempts to kick guest via signal
method of 'struct Interrupt' (devices/src/virtio/interrupt.rs) skips
sending a kick if prior kick is "not yet" acknowledged, which fails
if writes to VIRTIO_MMIO_INTERRUPT_ACK is asynchronous.
This patch introduces a 'async_intr_status' flag in signal method which allows
the kick to be always delivered to guest independent of the status of
acknowledgement of prior kicks. Hypervisor will queue kick requests and
deliver another kick after current kick is processed.
Its expected that only the Qualcomm wrapper program will initialize the
interrupt object with 'async_intr_status' flag set and hence the upstream
CrosVM should not be affected because of this change.
BUG=b:243368499
Change-Id: I76568d9d8bc3be00c75c52d4a51d39410c5c35b3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3965686
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Trying to reconcile the difference between the linux and windows
implementations.
Code relying on the eventfd count must now use the linux specific
`EventExt` interface.
BUG=b:231344063
TEST=presubmits
Change-Id: I14eb50f7a02d766a00f27aca388823309633e193
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3864030
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
The utils module contains code commonly used by backends, but not
necessarily used by all. This can lead to compiler warnings about unused
code depending on which backends are compiled in. Silence them by
allowing dead code in that module only.
BUG=None
TEST=`cargo build --features "video-decoder,video-encoder,libvda"` does
not emit any warning.
Change-Id: Ia5cb28f84a2367f450c69eb505347cc4a0d95ba1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3960215
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Upstreaming a fix from nkgold@ for the following issue:
ReadNotifiers shouldn't ever be reset as their state is managed by the
type that exposed the notifier (e.g. StreamChannel). Resetting it can
lead to lose notifications. idanr@ discovered that EventAsync::clone_raw
was creating a regular EventAsync (e.g. with reset), and it was being
used with read notifiers. This CL replaces clone_raw with a new factory
that produces `without_reset` EventAsyncs.
BUG=b:253255209
TEST=presubmit, downstream
Change-Id: I0b9de2f12cc3597ba05a8ac108f4cd0a8e726b3f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3960857
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Idan Raiter <idanr@google.com>
Currently, --tap-name, --tap-name, --host-ip...etc commands are all used
to create a vhost-user net device. This CL unifies the command line arguments.
BUG=b:246224081
TEST=run the following tests:
- `cargo test -p devices virtio::net::tests`
- `cargo test -p net_util`
Change-Id: Ie1342f23f0951e5a81e54547bf725c0d9be19f97
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3893869
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Koki Ryu <kokiryu@chromium.org>
This replaces the handwritten arg parser with the serde_keyvalue
based parser. Eventually we will unify the arg parsing with Unix.
BUG=b:233676779
TEST=cargo b --features all-msvc64,gpu --no-default-features
TEST=cargo t -p vm_control --features all-msvc64,gpu
--no-default-features
TEST=cargo t -p crosvm sys::windows::config::
--features all-msvc64,gpu --no-default-features
Change-Id: I36a563be9767c7e5cbd3ab44f6a9ba23cd64cdb6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3939033
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
It's not necessary to build 3D rendering support to run the
cross-domain context type.
Default implementations are added for some hypercalls, since
the guest kernel may still think it's running a KMS display.
That adds log-spam if errors are present.
BUG=b:173630595
TEST=Run weston terminal in the guest
Change-Id: I8155cf9d9867a329927b7dd4bb22c385510966a2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3961536
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
`tracing` conflicts with a crates.io crate. Since we may support tokio
tracing in the future, and want to submit some benchmarks against it
right now, we should rename our crate.
BUG=b:253517247
TEST=presubmit
Change-Id: I32bf64a7ce1830e881bd582e4606932782df65c6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3957598
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
As we always report the maximum number of displays (16), the kernel
would issue VIRTIO_GPU_CMD_GET_EDID for all displays even if they
are marked as not enabled. However, VirtioGpu::get_edid() would
return an error if the display is not enabled.
We could report some default EDID for disabled displays. Also
noticed that EdidBytes has 2 impl blocks, which doesn't seem
necessary, so they are merged now.
BUG=b:253482501
TEST=tested in Windows downstream
Change-Id: I666961fe33a6143b9d022049abf05be4ec757a8d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3957536
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
When decoding using libvda, the frame timestamp is truncated to 32-bits
and needs to be restored to its original value. This is done by doing a
multiplication with the truncation factor. However, if libvda gives us
an invalid timestamp, the multiplication can overflow and cause the
video device process to panic. Avoid this by switching to a wrapping
multiplication - the passed timestamp will still be invalid, but the
decoder device will signal an error instead of crashing.
BUG=None
TEST=cargo build --features "video-decoder,libvda"
Change-Id: Iabe683a997e0e9dea8c2bea53ef520f53868e590
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3958881
Reviewed-by: David Stevens <stevensd@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
The feature can be built but not tested without access to an intel
GPU.
To enable the build, the testvm and dev container are updated to
include libva.
BUG=b:244619376
TEST=presubmit
Change-Id: Ia8c4dc46ccbcd244bf57441f2c550a6b73c67b1c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3946027
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
- Spawn detached tasks with an AbortHandle like other devices.
- Bug fix: without calling queue.ack_features at the beginning of
start_queue, VIRTIO_RING_F_EVENT_IDX causes a hang.
BUG=b:243061269
TEST=presubmit, downstream
Change-Id: I03eba1c60a541cf7862feb434fc9fc1064319629
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3950853
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Idan Raiter <idanr@google.com>
... and include this information in the EDID blob.
BUG=b:163864461
TEST=cargo build
TEST=Android build
TEST=launch Cuttlefish with various DPIs and inspect
`adb shell dumpsys SurfaceFlinger`
Change-Id: I3f9ca0283f335d51063bf8e555ff2ffa7ead104b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3954473
Reviewed-by: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
Vhost worker uses the maximum queue size the host offers when setting a
queue size to the vhost device, which leads inappropriate behavior when
a guest preapares a virtqueue whose size is smaller than the maximum
size.
Fix the vhost worker to set the actual queue size to the vhost device.
BUG=b:235857465
TEST=`cargo build`
TEST=`./tools/run_tests`
TEST=host and guest can communicate via vhost-vsock
Change-Id: I99af745788c347ca2770b979252f8ea8dde34462
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3946422
Commit-Queue: Ryuichiro Chiba <chibar@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
1. gpu_control_tube is not used on Windows yet. We will make use of
it and test it in the downstream first before removing the Unix
feature flag.
2. In Gpu::keep_rds(), skip appending descriptors of stdout and
stderr since it is hard to find such descriptors on Windows, and
this function won't be called on Windows anyways.
3. Some functions in gpu_display should be guarded with gfxstream
feature flag, since we don't need to link against gfxstream
binary when we are building/tesing without gfxstream.
BUG=b:213149288
TEST=presubmit
Change-Id: I28c3d16d82916e6d4a542aa008dd09015141716c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3947825
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
While the current design works well for progressive content, in
interlaced content a common strategy is to decode both fields to the
same Surface.
Thus, add support for sharing the underlying Surface. This means that we
can only retrieve the Surface if we are the last Picture with a
reference to it.
While we are at it: only retrieve Surfaces if we are the last users
In preparation for interlaced decoding support, only retrieve Surfaces
back into the surface pool if we are the last users. This means that the
surface will not be dropped until both of its fields have been dropped.
BUG=b:214478588
TEST="cargo build --features=video-decoder,vaapi" successfully
builds the libva crate
Change-Id: I80412a86f51ab639fab6af229572fb7bc800a928
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3946300
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
When we detect a VCPU stall we propagate the watchdog reboot error code
to the event tube. The newly added error code WATCHDOG_REBOOT = 36 is
returned from the crovm process.
Bug: 245900797
Test: manual testing, build and Virtualization apk on a device
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Change-Id: Ib1ce97de911784b33d130d40536be26813edc3d7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3936647
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The current crosvm implementation is using
`GuestMemory::checked_offset()` for the following two cases:
(1) To get a valid `GuestAddress` representing `addr + offset`.
(2) Guarantee that the memory range `[addr, addr+offset]` is valid.
However, using `checked_offset()` for the case (2) is wrong because the
method only checks if the end address `addr+offset` is valid and doesn't
check if an invalid region exists between `addr` and `addr+offset`.
So, this CL adds `GuestMemory::is_valid_range()` to replace the (2)
cases.
BUG=b:251753217
TEST=cargo test in vm_memory
TEST=start a vm with virtio devices
Change-Id: I21bce5d1c60acdff79284cdad963849a6e19e19c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3945520
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Adds `crosvm gpu <>` commands which allows for interactively
adding/listing/removing virtio-gpu displays/scanouts.
Also updates the virtio gpu device to use a Map<u32, Scanout>
instead of a Vec<Scanout> and always report the maximum number
of displays (16) with enabled/disabled. This helps handle the
case of removing a display that is not the last display number.
BUG=b:163864461
TEST=cargo build
TEST=cargo build (with gpu feature disabled)
TEST=Android build
TEST=launch Cuttlefish
TEST=crosvm gpu list-displays <socket>
TEST=crosvm gpu add-displays
--gpu-display=width=900,height=600
--gpu-display=width=600,height=480
<socket>
TEST=crosvm gpu list-displays <socket>
TEST=crosvm gpu remove-displays
--display-id=1
<socket>
Change-Id: I7530498897eb4e84199eaeb3d66df006df62817f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911102
Commit-Queue: Jason Macnak <natsu@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Without _PRx method, device couldn't put into D3cold. In order to
put vfio-pci device into D3cold in VM, this commit add _PRx method
for vfio-pci device. When guest call _PRx method, crosvm will trap
it and forward the _ON/_OFF request to host vfio-pci kernel driver
which manage physical device PM.
BUG=b:194390621
TEST=dump ssdt table in a guest with vfio-pci device
Change-Id: I5ec6ebc84f5328574b62b2d6e091ffe9605d1dd4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822009
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Victor Ding <victording@chromium.org>
The Suspendable trait's restore() function allows returning a Result, so
we can use the `?` operator to return errors in case the serde_json
deserialization process fails, rather than using `unwrap()` on the
Result, which would panic if the call failed. This doesn't make much
difference for this particular case, since it is in test code, but we
should provide a good example in case this code gets copied for other
implementations of the Suspendable trait.
BUG=None
TEST=cargo test -p devices
Change-Id: I8252fef5ee8f19c73f08971352984cd91766aa0c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3942512
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Elie Kheirallah <khei@google.com>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Allow devices to perform runtime power management via
VFIO_DEVICE_FEATURE IOCTL.
BUG=b:194390621
TEST=host's VFIO_DEVICE_FEATURE can be triggered from guest
Change-Id: Id649a1e5fe317dfb315f841a152ec8b81fab8e7c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3822004
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Victor Ding <victording@chromium.org>
Use the new ability of serde_keyvalue to parse tuple enums to directly
parse display arguments into their target struct. This requires an
incompatible update on the syntax, but it doesn't seem to be used on
Unix anyway.
Windows code still uses its own parser so it is not affected by this
change.
TEST=cargo test --features "gpu" parse_gpu
Change-Id: I2b718600015a57f5dd6675e9d60de3b8c149a80f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920254
Reviewed-by: Pujun Lun <lunpujun@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Fix a few stray references to "CrosVM" and "CrosVm" so that we refer to
the crosvm project with consistent capitalization.
BUG=None
TEST=None
Change-Id: If5c3c131774d6e5da1d27466810642aec3cb42ac
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3938640
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Adds a new message that can be used to map GPU memory via Vulkano.
BUG=b:244622199
TEST=presubmit & downstream
Change-Id: I4018cfda7573d4df2d89225060d5d61c8ac5d3d9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924935
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Idan Raiter <idanr@google.com>
Reviewed-by: David Stevens <stevensd@chromium.org>
Add a new identifier for a device, the "device id". This is a
combination of the device UUID + driver UUID. Reason for not only using
device UUID is that the spec calls out both must match:
https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#external-memory-handle-types-compatibility
We have also seen some less-ideal implementations of device UUID on
Windows that return mostly zero with a few bits set, so adding the
driver UUID should increase confidence.
physical_device_idx is removed.
BUG=b:244622199
TEST=presubmit & downstream
Change-Id: I8174227e3d4bcadf778b7a73c9f84bb475169326
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3926105
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Idan Raiter <idanr@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
