Closing the uring fd should release the resources borrowed by the kernel
so there's no reason to call io_uring_enter to drive any pending IO to
completion. Doing so may end up blocking the thread indefinitely.
Instead just make sure that the URingContext is dropped before anything
else. Rust's drop order guarantees that struct fields are dropped in
the order of declaration so this just means putting it first.
Also, since the RawExecutor is wrapped in an Arc it may end up being
dropped from a different thread than the one that called run() or
run_until(). We know there are no other references so just clear the
cached thread_id so that we don't panic in the drop impl. We don't
currently have any users that want to run the executor concurrently on
multiple threads so we'll just punt that problem until we actually need
to deal with it.
BUG=none
TEST=unit tests
Change-Id: Icf6a23fc433128dd00adbd56a715dbae24cd8ea2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643845
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
IORING_OP_NOP is a no-op that does no IO and can be used to measure the
performance of the io_uring subsystem or to wake up a thread currently
blocked inside an io_uring_enter syscall. Use it instead of keeping a
separate eventfd.
BUG=none
TEST=unit tests
Change-Id: I3b3e93c653e1db747c90456c1d93abb979c25d34
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643844
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Rather than requiring callers to wrap the entire UringContext in a big
lock, make UringContext Sync by internally using fine-grained locks:
* The submit queue is wrapped with a Mutex so that threads may still add
operations to the submit queue even when a thread is blocked
inside an io_uring_enter call.
* The completion queue internally uses a Mutex around the pending op
data and completed count so that two threads don't end up trying to
remove the same operation from the completed queue.
With this we can enable the await_uring_from_poll test. This test
uncovered missing wakeups in the case where a uring operation is added
from one thread while the main uring thread is blocked inside an
io_uring_enter syscall. To deal with this, we call submit() whenever the
pending operation is polled and not yet submitted.
BUG=none
TEST=unit tests
Change-Id: I4c7dec65c03b7b10014f4a84d2cd16fe8758ea72
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643842
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This is like future::task::ArcWake but uses Weak<T> instead of Arc<T>.
This prevents a circular reference where the RunnableQueue would hold an
active reference to the executor (via its waker) while the executor
owned the RunnableQueue, leading to memory leaks.
With this the executor should only be using weak references internally
and the only strong references should be in the public *Executor type.
Also fix the tests that were broken by this change.
BUG=none
TEST=unit tests
Change-Id: I3e9c007d533e154b2ad9d1e4d56a692f65da6aa0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643841
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
There are a lot of changes in this one but these are the high-level
points:
* Both executors now support non-fd futures and it's now possible to
start a poll operation on one thread and then await the result inside
a UringExecutor on another thread. The reverse doesn't work yet but
will once we make UringContext sync.
* A few layers of indirection have been removed so hopefully both the
implementation and the interface are simpler.
* The thread local magic is gone in favor of directly calling methods on
an executor. Executor handles can be cheaply cloned to make this
easier.
* Heap allocations are limited to the spawn and spawn_local methods so
it's possible to completely avoid heap allocations if callers only use
the run_until method.
* The IoSource, Executor, FutureList traits are gone.
BUG=none
TEST=unit tests
Cq-Depend: chromium:2629068
Change-Id: I86053007929c36da66f3b2499cdefce0b5e9a180
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2571401
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This change serves two purposes. The FDT needs to be in a location
accessible by 32 bit devices. Secondly the FDT's location was dependent
on the amount of RAM allocated to the guest prior to this change which
made passing it's location to the BIOS challenging.
By moving the FDT to a fixed location within the 32 bit accesible memory
boundary, these problems have been fixed.
BUG=b:177926450
TEST=local boot of android virtual device on ARM host
Change-Id: I89e481f66ddc8ffcf0e86f00fbfa92d407c48736
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2641126
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Ram Muthiah <rammuthiah@google.com>
Commit-Queue: Ram Muthiah <rammuthiah@google.com>
A few things happened:
- A recent minigbm change broke compilation for debian, so
I am pinning the commit SHA for the Dockerfile.
- Newer rust versions come with new clippy errors, which I will
have to look at in a separate change. For now I am pinning our
rust version.
- Some repos have transitioned to a main branch. Fixed our uprev
script to handle those.
- Renamed SYSROOT so we won't confuse pkg-config.
Now Kokoro is finally happy again!
BUG=None
TEST=wrapped_smoke_tests
Change-Id: I76294abe35fd84b305124158b3942a321651982d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2643779
Tested-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The ./run_tests script will select which tests to run on the host.
Unfortunately a lot of our tests require dependencies or access
to certain kernel devices. We cannot run all tests on all hosts.
The test runner works with the CI builders:
To run all x86 tests:
./ci/builder ./run_tests --all
To run tests on aarch64:
./ci/aarch64_builder ./run_tests --all
Or to just run tests that can be run on a standard debian buster
system without obscure chromeos dependencies:
./run_tests
Eventually, the test runner should run tests via the VM of the
aarch64_builder, currently only those tests that can be run with
user-space emulation are executed.
Currently some tests remain disabled in the runner, as they do not
pass in the CI builders yet. These will be enabled as the builders
are set up to allow for them to be run.
BUG=b:173833661
TEST=Ran the above commands.
Change-Id: Id69027793348f4d3f20adf5333d8bdfff1aa9c8b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2633889
Tested-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
This USB ioctl is used in usb_util::Device::clear_halt(), but it was not
allowed in the seccomp policy.
BUG=chromium:1167286
TEST=Attach Keyspan USA-19H USB serial adapter to Crostini
Change-Id: I625cde121a0a248046e476eecd732a98530811dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2633824
Reviewed-by: Matthew Blecker <matthewb@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Matthew Blecker <matthewb@chromium.org>
Commit-Queue: Matthew Blecker <matthewb@chromium.org>
Annotate the THREAD_SYNC flags with allow statements so that clippy does
not complain about them.
BUG=None
TEST=bin/clippy
Change-Id: I9d9d5d5b2a5f51e3ce49c36dd7528ad677aeb30e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2638139
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This CL expands the existing boot.rs test to not just boot a kernel
but also provide a debian-based rootfs and a special init binary
that is used to communicate between test code and the guest VM.
The delegate binary listens for commands on /dev/ttyS1 and returns
the stdout of the executed command.
This allows the test code to setup pipes for the serial device to
issue commands in the client and receive the command output, which
provides a good foundation for tests of basic functionality without
the need to pass test binary code into the guest.
The integration tests will pull a prebuilt kernel and rootfs image
from cloud storage unless local files are specified via ENV variables.
The integration_tests/guest_under_test directory contains the files
needed to build and upload those prebuilts.
BUG=b:172926609
TEST=This is a test.
Cq-Depend: chromium:2551073
Change-Id: Iffb88a146a13d1b6ed7250df1b487bd87a5599d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2536831
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Auto-Submit: Dennis Kempin <denniskempin@google.com>
This CL adds the foundation for running tests consistently
in Kokoro and locally, for both x86 and aarch64.
The crosvm_builder is similar to the original image from
docker/crosvm.Dockerfile.
The main difference is that ChromeOS dependencies are not
compiled into the container, but built at runtime.
The crosvm_aarch64_builder installs the build enviornment
to cross-compile crosvm for aarch64. The tests are run
with user-space emulation using qemu-aarch64-static.
See ci/README.md for instructions on how to use these
builders.
Tests on aarch64 cannot all be run using user-space
emulation. We will need a VM to pass all smoke tests,
this work is tracked in b/177228167.
BUG=b:177133814
TEST=Tested by running
./ci/builder bin/smoke_test
./ci/builder cargo test
./ci/aarch64_builder cargo build
./ci/aarch64_builder cargo test -p tempfile
Change-Id: Iffffcf48894787dd72fff894af351fdaced0b429
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2621994
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Make it stand out in logs and easier to `grep` for the message in
automated scripts such as tests.
BUG=b:152259067
TEST=Introduce failure in crosvm and try booting ARCVM
Change-Id: I0ca76f8a68eb650c95e072224d0a9d019696ac6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2413914
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: Junichi Uekawa <uekawa@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Junichi Uekawa <uekawa@chromium.org>
This is ABI-compatible with iovec and comes with Send + Sync impls,
which iovec does not have.
BUG=none
TEST=unit tests
Change-Id: Ic5831f557933b1d0dc823b1f6ba991ffe57baf2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2571149
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
This should hopefully make it easier to distinguish it from
std::io::IoSliceMut.
BUG=none
TEST=unit tests
Change-Id: I0746239c23e014cdccac62f1b89ec78f4008d22c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2627238
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Move the RutabagaIovec representing the display framebuffer out of
match's Some() condition so that it outlives the call to the
underlying renderer.
BUG=b:173630595
TEST=launch_cvd --gpu_mode=gfxstream
Change-Id: I86b2ddd0de0551bf0fbbbfebf811c39d7581f3cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2627646
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
The fuzz_server interface was updated to require a Mapper; however,
fs_server fuzzer was not updated to provide one, and it does not seem
necessary since the Mapper calls don't affect control flow in the
server. Instead, just provide a no-op Mapper inside fuzz_server.
Fixes fs_server_fuzzer build.
BUG=chromium:1166742
TEST=FEATURES=test emerge-amd64-generic crosvm # --profile=asan
Change-Id: I6f2d2c7156056976a2e5dd1d7b5a29a231608150
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2629970
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
This seems to be faster than using UC and brings perf close to or
on par with goldfish address space blobs.
BUG=b:177241396
Change-Id: I8198ac0a0510388e79753cdb22007f97dcb3568b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2621997
Commit-Queue: Lingfeng Yang <lfy@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Lingfeng Yang <lfy@google.com>
The encoder should be able to start encoding when receiving 1 input
buffer. This CL changes the minimum input buffer from 2 to 1.
BUG=b:175745193
TEST=android.mediav2.cts.EncoderProfileLevelTest
Change-Id: I97060d0304cf41369467dc62d12bbae7e54b6b22
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2602299
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
Introduces new struct/impl BalloonPolicy that manages the size of the
virtio balloon.
Instead of the balloon balancing available memory between the host and
guest, available memory above the critical margin is balanced. Where
critical margin is the level that the host/guest starts reclaiming
memory or killing processes. See comments above impl BalloonPolicy for
explanation.
In addition, balloon size dependent bias is introduced to encourage
large balloons to deflate, and small balloons to inflate. This bias is
needed for multivm.LifecycleShifting.arc_host to pass, as sometimes
without the bias the balloon is inflated so much that the first App in
a streak times out when launching. The bias also reduces variance in
multivm.Lifecycle.arc_host.
BUG=b:172870597
TEST=tast run dut mutivm.Lifecycle.* multivm.LifecycleShifting.* x10
Change-Id: I241e470aece56e3dc53fe59f833a1f7f4f684299
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2596293
Tested-by: Charles Dueck <cwd@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Charles Dueck <cwd@chromium.org>
The decoder should be able to start decoding when receiving 1 input
buffer. This CL changes the minimum input buffer from 2 to 1.
BUG=b:176266656
TEST=android.media.cts.DecoderTest#testEOSBehaviorVP8
Change-Id: I2b055b145993d35c00a07bc7081db84117e36423
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2602297
Tested-by: Chih-Yu Huang <akahuang@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Chih-Yu Huang <akahuang@chromium.org>
It's possible to compile the gpu device without virgl_renderer.
In fact, in many instances, this may be required.
This builds the gpu device default, but only with --gpu do I see
/dev/dri/renderN128, so this should be safe.
BUG=b:173630595
TEST=compile and run
Cq-Depend: chromium:2592111
Change-Id: I5fbf2de8a2f818a9ca2e5ac4a1a02c7797cff927
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2592089
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
This makes the links work regardless of the name of the main branch.
BUG=None
TEST=Navigate to the URLs in a browser
Change-Id: I2daaa077e77e923313fecb23e6afde2e951d82a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2596050
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Support virtio-fs's DAX (direct memory access) operation which allows the guest
to directly access file pages.
Specifically, FUSE_SETUP_MAPPING and FUSE_REMOVE_MAPPING operations are
supported.
This option can be used by specifing `dax` option when mount a file system in
the guest.
The DAX optoin improved file I/O performance in most cases.
In Fio tests, both of read and write score were improved by 1.3-14x depending on
test cases.
In Blogbench tests, which create many small files, DAX improved the write score
by 1.5x while the read score was reduced to ~25% (20391 -> 4593).
Here is an excerpt of results:
Fio
* seq_read: 10.2x (143528 -> 1464911)
* seq_write: 3.3x (61253 -> 896791)
* rand_read: 11.6x (138753 -> 1612739)
* rand_write: 14.6x (61253 -> 896791)
* surfing_read: 1.3x (98473 -> 127907)
* surfing_write: 1.3x (83309 -> 108089)
Blogbench
* read: 0.23x (20391 -> 4593)
* write: 1.50x (248 -> 373)
BUG=b:147341783
TEST=Run vm.{Blogbench, Fio} with CL:2291856
Change-Id: I4a47c601412ed32d926de6304337e1594252d258
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2108315
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Update all git repositories to the latest after verifying the tests
still pass.
BUG=None
TEST=docker/build_crosvm_base.sh && docker/wrapped_smoke_test.sh
Change-Id: Ie5e93ce76c0a180dea36e3909b16de8900b6461a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2593458
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
clippy 1.48.0 has a bug in string parsing in doc comments.
https://github.com/rust-lang/rust-clippy/issues/6022
To avoid this issue, update to use double-quotation instead of single-quotation
inside a code block in a doc comment.
Also, this fixes wrong examples of commands there at the same time.
BUG=none
TEST=bin/clippy
Change-Id: I90e5699f6d4e839304f9d4e05e5c7b21467744cd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2592001
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
This CL adds support for VIRTIO_VIDEO_CONTROL_FORCE_KEYFRAME to the
crosvm encoder.
BUG=b:161498590,b:174444769
TEST=tast run DUT arc.VideoEncodeAccel.h264_192p_i420_vm
Change-Id: Ibe0c7d2aa7b41c6a0168a7aa312d6996cc22ef23
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2567308
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This test was useful for debugging issues with the hypervisor
abstraction layer while it was in development. It's similar to some of
the kvm integration tests, but runs the x86_64 setup functions. It has
some commented out lines for having this test load a real kernel and/or
ramdisk, which can also be useful for debugging boot problems.
RESTRICT_AUTOMERGE
BUG=b:175025264
TEST=cargo test -p x86_64
Change-Id: If5b89fe48d34db50fb962382032881e4e588db6e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2579896
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This error was observed:
wl_surface@5: error 3: buffer committed to unconfigured xdg_surface
Shout out to bugaevc for the diagnosis and fix:
"In addition to setting up the listeners, we have also made two
important changes. First, we call wl_surface.commit right away,
prior to attaching any buffer to it. This causes the compositor to
issue the appropriate configure events. We wait for them to be
received and handled with an additional wl_display_roundtrip() before
we attach the buffer."
https://bugaevc.gitbooks.io/writing-wayland-clients/content/beyond-the-black-square/xdg-shell.html
BUG=b:150239451
TEST=boot VM with wayland display, still doesn't work completely
correctly due to lack of {import, attach, detach}_event_device
implementations
Change-Id: I06fac4f8540ce410c20a367d1e5dbe3fc08c4f10
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2583164
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Currently only H.264 level 1 is reported to the virto encoder when the
supported H.264 levels are queried. This CL expands the list to contain
all levels up to 5.1 which are supported by most devices, as the VEA
interface currently has no way to query the maximum supported H.264
level.
BUG=b:174967472
TEST=android.media.cts.MediaRecorderTest#testProfileAvcBaselineLevel1
Change-Id: I960f9176fa00180da6f71bcdad558da06e8247c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574583
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
Currently only the framerate requested on the CAPTURE queue is used to
configure the Chrome encoder's framerate. But according to the V4L2
standard setting the framerate on the OUTPUT queue should also set the
framerate on the CAPTURE queue to the same value.
BUG=b:173668157
TEST=android.media.cts.MediaRecorderTest#testProfileAvcBaselineLevel1
Change-Id: I0753d10d73d52ce4f17fd9bc230d4fa2f06a1b30
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2570833
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: David Staessens <dstaessens@chromium.org>
Commit-Queue: David Staessens <dstaessens@chromium.org>
