This isn't necessary, but it does aid readbility in my opinion.
BUG=b:231344063
TEST=cargo build && ./tools/dev_container ./tools/run_tests --target=host --build-target=mingw64 --build-only
Change-Id: Id486d66773a15f1a544f717aab508d5006be3553
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3864026
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Current implementation does not allow hot-resizing feature to be used in
vhost-user block devices because the backend device cannot notify the
frontend that the device configuration has changed. Fix this by adding
and establishing the backend to frontend vhost-user message connection to
the vhost-user block backend, send the HANDLE_CONFIG_CHANGE_MSG to the
frontend, and send interrupt to the guest kernel from the frontend
device when receiving the message.
BUG=b:191845881
TEST=cargo run devices -s /path/to/socket.sock --block ...
cargo run run --vhost-user-blk /path/to/vhost-sock,
cargo run disk resize 0 $SIZE /path/to/socket.sock
Change-Id: Ifab75d65c429dfcea5e632b899f014278a6e6750
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3859218
Commit-Queue: Keita Suzuki <suzukikeita@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Morg <morg@chromium.org>
Current implementation of vhost-user backend devices cannot directly
send vhost-user messages from the backend to the frontend since the
established connection is stored directly to `VhostShmemMapper`. This
limits the messages that could be sent to memory share-related messages.
To overcome this limitation, introduce struct `VhostBackendReqConnection`
which exposes the required backend to frontend requests and keeps track of
the underlying transport (struct `Slave`), and refactor `Slave` out from
current VhostShmemMapper.The state of the connection is managed using enum
`VhostBackendReqConnectionState`.
This patch also moves the timing of when `BackendReqHandler` is created in
the frontend to when `VhostUserProtocolFeatures::SLAVE_REQ` is negotiated
when creating VhostUserHandler.
BUG=b:191845881
TEST=run ./tools/run_tests
Change-Id: I90235a527d58067f73a509907b4cefc09516f562
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3856036
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
FromStr trait is manually implemented for ExecutorKind, but
serd_keyvalue should be preferred. This commits refactors ExecutorKind
so that derives serd_keyvalue.
BUG=None
TEST=`crosvm --async-executor (epoll|uring) run ...` works
TEST=test passes on linux and windows
Change-Id: I5aafb6704c20a17120b30c290e1a4069dff9e5ce
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924880
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Takaya Saeki <takayas@chromium.org>
The INVALIDDATA error can be returned by both try_send_packet() and
try_receive_frame(). In both cases we should just skip the invalid input
until the decoder can catch up with something that makes sense.
TEST=arc.VideoDecodeAccel.h264_vm unconditionally passes on Hatch
Change-Id: I4467b50c35fb36562a4b662d14071afcf02f1eb2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924583
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Try to recover from a fatal error by resetting all streams instead of
exitting and putting the device into an unrecoverable state.
On error, all workers will be stopped and streams will be reset, then
workers will be restarted.
Flag `just_reset` will be set on all stream after a reset. This flag
let the invalid state transition to return Ok instead of Err. This let
the guest driver able to stop the stream even when the state is
desynced from device side. Once a valid state transition is made, the
flag is removed.
BUG=b:242021318
TEST=`restart cras` while playing music and recording audio in ARCVM
TEST=`restart cras` while calling `aplay` and `arecord` in termina
TEST=unit test
Change-Id: Ic329e2f82e572e6fcd69a6a197909b494d0360b5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3823181
Commit-Queue: Pattara Teerapong <pteerapong@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Refactor run_worker by extracting the worker running logic to
run_worker_once function.
BUG=b:242021318
TEST=play music and record audio in ARCVM
Change-Id: Idb2012b92fc113db9b8e16c066e10b72f66a7cdb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3889334
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Commit-Queue: Pattara Teerapong <pteerapong@chromium.org>
The existing file descriptor must refer to a listening socket.
TEST=cargo test, added a new unit test
BUG=b:238931628
Change-Id: Ia6bd5d6d30af69fb4b5fa00865f5528f19f569d9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3932714
Commit-Queue: Keir Fraser <keirf@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We were busy-waiting on atomic variables for the message loop
state of the WndProc thread. That is to make sure other threads
don't start posting messages to the WndProc thread until the
latter has created the message queue and is about to enter the
message loop. We can use mpsc channels instead. The WndProc
thread notifies other threads that it is ready by sending out its
thread ID.
BUG=b:243184256
TEST=tested in downstream
Change-Id: Ia2a675c083bb6aa9046dd9eab932a95fa06b8709
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3928133
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
We were busy-waiting on atomic variables for surface creation
results. We can use mpsc channels to avoid that, which also
eliminates the need for enum CreateSurfaceResult since we just need
to send booleans.
BUG=b:243184256
TEST=tested in downstream
Change-Id: If4c39c797f9ca9edf3695e44689904066546759f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3928131
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Fix a few recently introduced formatting mismatches.
Change-Id: I1617683532d3cc45f67ec15408fbd4ec4c9d6bb2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3928132
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Fuzzer targets can be ran with
cargo +nightly fuzz run --fuzz-dir crosvm-fuzz --features
upstream-fuzz <target>
This should enable us to move fuzzing to anywhere including
ClusterFuzz while maintain compatibility with cros infra.
TEST=`cargo fuzz` won't crash in first 30s,
`USE="asan fuzzer" emerge-hatch crosvm` builds,
`/build/hatch/usr/libexec/fuzzers/crosvm_qcow_fuzzer` won't
crash in first 30s
FIXED=b:245007212
BUG=b:244631591
Change-Id: I4b262ee1a6a90247dea96347c55a3849af793bec
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3905095
Auto-Submit: Zihan Chen <zihanchen@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
backend"
This reverts commit 03fdffb447.
Now b:249692652 is fixed by crrev.com/c/3842811/, we can bring back the
command-line option to switch Executor backend.
This commit is identical with the original CL, except it resolving the
conflict with ccrev.com/c/3841945/; it renames the old `use_uring` in a
test to the new name, `is_uring_stable`.
(cros_async/src/sys/unix/uring_source.rs:652)
BUG=b:249692652
BUG=b:239154263
TEST=confirmed crosvm --async-executor correcly switchs the Executor for
`crosvm --async-executor epoll (or uring) device gpu --socket
/tmp/gpu.sock` command. Used additional debug log to tell which
executoris running, which is not commited)
TEST=all tests passed
Change-Id: Iafb6921c1a7594a178712eb46792dc54d5d99f71
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3931568
Commit-Queue: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
It's not ergonomic for the calling code to pass in an array of
references.
Just take ownership of that array, as it's not going to be used again
when the calling code succeeds in creating the wrapper.
BUG=b:214478588
TEST="cargo test"
Change-Id: Ifbb78968ebb29b41fe2ccaa653f30a81fcb23427
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3783002
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
pread only works for seekable files, so, for example, a pipe could not
be used. The non-async Console uses read calls and doesn't have this
issue.
There is a possibility of breaking something with this change. Suppose
crosvm was passed an input FD with the cursor at the end of a non-empty
file. Before the async console would read the full file from the
beginning, but now it would immediately EOF.
Another difference is that if the device is reset and then reactivated,
it will continue reading from where it left off instead of restarting at
the beginning of the input.
In both cases, I think the new behavior is better and additionally
matches the non-async console's behavior. The async console is
relatively new, so hopefully no one is depending on this part of its
behavior yet.
BUG=b:243198718
TEST=presubmit
Change-Id: I8e07e231d5def250eb5f42e9a4546fce721cc4bc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3842811
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Frederick Mayle <fmayle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The `ReadAsync` and `WriteAsync` traits accept file offsets as an
`Option<u64>`. The epoll executor interprets `None` as "current file
position" and the io_uring executor interprets `None` as position zero.
This change updates the io_uring executor in favor of the epoll executor
behavior.
It is important to differentiate between position zero and "current file
position" when you don't know whether a file is seekable. For example,
console and serial devices should support both types of files as input.
BUG=b:243198718
TEST=presubmit --all
Change-Id: I01634e6bbdff352c0a6055419d0fafd10c0c40a6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3841945
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Steven Moreland <smoreland@google.com>
Reviewed-by: Takaya Saeki <takayas@chromium.org>
A rebase appears to have caused memory imports to allocate external
memory instead of import it. For example, the input handle is not used.
- Fix the issue and make the import cross-platform. Linux / Windows use
different extensions.
BUG=b:244622199
TEST=presubmit & downstream
Change-Id: Iaeefa37526d42e23be521a97c9ca038659fefb11
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3926104
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Idan Raiter <idanr@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Make it official that setting a Timer's interval to 0 is the same as
setting it to None, meaning it will not be periodic. Fixed the windows
timer to behave this way again, and updated Timer docstring.
Also updated APIC timer to use None for interval which is clearer.
Bug: b:248612697
Test: tested with UserspaceIrqChip in dynamic tick mode
Change-Id: I57713c3ace345a8c64b9219a8e60f36c54a9481c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3925006
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
An existing file descriptor is specified by a path of the form
/proc/self/fd/<fd>. In this case crosvm will use this existing
listener socket directly, rather than trying to create a fresh one at
the specified path location.
This is useful for sandboxing crosvm in an environment in which it is
unable to create new filesystem entries.
BUG=b:238931628
TEST=Tested downstream
Change-Id: Ic6b24196bbe01960aedfe3f00ec69fd799e6ba91
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3928022
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Keir Fraser <keirf@google.com>
The FFmpeg backend is a software emulated video encoder device backend.
It can be used for testing, for developing guest kernel changes and
more.
The backend roughly mirrors how the FFmpeg decoder backend is
implemented right now, with the notable difference that it does not use
swscale as the de-facto input format is NV12 or YUV420 and the guest can
likely provide buffers in that format.
BUG=b:239897269
TEST=See testing instructions in the updated book document.
Change-Id: Iae9928bdad86729f890e738acfa58e21573a115b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920263
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
For simplicity, use the same error type as Format -> AvPixelFormat.
This will be used and tested in the FFmpeg encoder backend.
BUG=b:239897269
TEST=cargo build --features "video-encoder,video-decoder,ffmpeg"
Change-Id: Ie5cf2a29379c0d52c78cee50ed6571f4859eee75
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924881
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
As a convention, error types should always implement Error, so we're
doing it here.
The traits are manually implemented as opposed to using ThisError; it
was simple enough, and using ThisError requires making the error type an
enum which makes it more verbose to construct.
BUG=None
TEST=cargo build --features "video-decoder,ffmpeg"
Change-Id: If94926c1b2f14295b29c877c2c70d361b4adee90
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3925332
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This reverts commit cb6e74a094.
Reason for revert: This CL itself is fine, but b:249692652 reported
that virtio-console has been broken with epoll executor. cb6e74a0 also makes this broken virtio-console, which is confusing for users of virtio-console. cb6e74a0 can be merged again with the workaround for the default executor or after b:249692652 is fixed.
Original change's description:
> cros_async: add a command-line option to switch Executor backend
>
> Currently Executor internally decides which backend to use, such as
> FdExecutor vs URingExecutor on Linux. This makes it hard to test both
> FdExecutor and URingExecutor. In addition, we came across the uring
> instability issue (b:238965061), thus we need a way to explicitly switch
> the polling backend to mitigate the issue.
>
> This commit adds a command-line option to explicitly configure the
> Executor's polling backend.
>
> BUG=b:239154263
> TEST=confirmed crosvm --async-executor correcly switchs the Executor for
> `crosvm --async-executor epoll (or uring) device gpu --socket
> /tmp/gpu.sock` command. Used additional debug log to tell which executor
> is running, which is not commited
>
> Change-Id: Ib310d9edc8ab6005f1b7f210b03668b9a45fa73f
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3811014
> Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
> Commit-Queue: Takaya Saeki <takayas@chromium.org>
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Reviewed-by: Noah Gold <nkgold@google.com>
Bug: b:239154263
Bug: b:249692652
Change-Id: I15f575597534cea6004bca4679245ef958bbe1e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3925329
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
This abstracts away the cross-platform differences: cfg(unix) uses a
Unix domain stream socket to connect to the vhost-user backend, and
cfg(windows) uses a Tube.
BUG=b:249361790
TEST=tools/presubmit --all
Change-Id: I47651060c2ce3a7e9f850b7ed9af8bd035f82de6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924834
Reviewed-by: Richard Zhang <rizhang@google.com>
Reviewed-by: Noah Gold <nkgold@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Now that we've made VirtioGpu::export_fence() and
VirtioGpu::export_resource() compile on Windows, we can make
resource bridges related code compile there as well. We are adding
an assert to make sure it is not really used on Windows, though,
since that is unsupported.
BUG=b:213149288
TEST=presubmit
TEST=tested in downstream
Change-Id: Iad06055c0aff5b6ce1fa6cb7bc0d0789750033bd
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3928606
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
This snuck through because it's only compiled for chromeos. The feature
will be split out and enabled on upstream builds in https://crrev.com/c/3924741
to prevent failures like this in the future.
BUG=None
TEST=emerge-amd64-generic implicit-system crosvm
Change-Id: Id74c59a5a5a765bfbe5864ee9588ab9863b18bc7
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3929079
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Per virtio-video spec, if the device encounters a field with value it
does not support, it should update the field with a valid value and then
return that.
It's actually debatable whether an empty plane array is allowed in the
first place, but this seems to be what happens in the case we use a non-
default format (everything but NV12) from FFmpeg v4l2m2m. Moreover, the
guest kernel currently ignores SetParams errors, so it seems justifiable
that we should avoid rejecting this input and instead gracefully handle
it.
With this change + later commit introducing the FFmpeg encoder, FFmpeg
in the guest works with `-pix_fmt yuv420p -c:v vp8/h265_v4l2m2m`. Note
that for VP8 a WebM container should be used. VP9 was not supported as
an encoder accelerator somehow so this was not tested.
BUG=b:239897269
TEST=cargo test --features "video-encoder,video-decoder,ffmpeg" -p devices video
TEST=Linux guest test described above
Change-Id: I843af7cef35cc231b8668efcf716a48a37959c86
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924264
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This is required to get H.265 and VP8/9 to work in the FFmpeg backend.
BUG=b:239897269
TEST=cargo test + FFmpeg backend tested in later commit.
Change-Id: I1d5b3305e688ddab82f8a4afe84dc7438ee27b2b
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924263
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
We were already accepting AvFrame for swscale inputs, but for the output
a different SwConverterTarget trait was being used.
The old interface had a few issues:
- The use of memory mapping traits, putting a dependency on crosvm/base
- Insufficient metadata, not being able to represent custom padding on
the stride or non-contiguous plane layouts
- Inconsistency between input and output types
In this patch, we:
1. Introduce a AvFrame-based API to replace the old SwConverter API.
2. Add a TryAsAvFrameExt extension trait inside devices/ to convert
virtio handles to AvFrames.
(This is placed inside devices to avoid ffmpeg depending on base.)
3. Add a new wrapper type, MemoryMappingAvBufferSource, that wraps a
MemoryMappingArena and implements AvBufferSource for it. This was
technically not sound, but it's a low-risk attack vector that we
implicitly allowed before. The patch doesn't change the behavior; it
just makes this assumption more explicit.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: Id15e19b7d2452d1bc722a65f941c2c9150876205
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3889245
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
In case of GuestPages the stride is obtained from the SetParams request
which is specified as 0 for output buffers in the virtio-video protocol.
This obviously doesn't work, and replacing the use of stride with the
plane size fixes it.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: I2ed584c647400802b875a9d68fc8ede1a9db0db0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920262
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This adds:
- A buffer size field for each plane
- Width, height, format field for each image
This is for introducing helpers to convert video GuestResources into
AvFrames.
In practice, these metadata were readily available either from the
protocol or through rubataga RPCs, but they have not been stored in the
GuestResource struct. With these change these fields would be available
for usage in constructing AvFrames.
A tricky topic is the source of the metadata. Right now, neither the
virtio_video_params struct nor virtio-gpu backend metadata alone can
provide all the metadata we need. See code comment in
GuestResource::from_virtio_object_entry and go/crosvm-enc-ffmpeg for
future work discussions.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: Icb47274d2dd379a10bdf878ed91ffbc238685c6d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911110
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This is generally more useful when it shows up in log messages.
BUG=b:244553205
TEST=tools/dev_container tools/run_tests
Change-Id: Idbaa58f7a9fdb8e69212074fb5853da9098a82fb
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3921603
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Andrew Walbran <qwandor@google.com>
Currently Executor internally decides which backend to use, such as
FdExecutor vs URingExecutor on Linux. This makes it hard to test both
FdExecutor and URingExecutor. In addition, we came across the uring
instability issue (b:238965061), thus we need a way to explicitly switch
the polling backend to mitigate the issue.
This commit adds a command-line option to explicitly configure the
Executor's polling backend.
BUG=b:239154263
TEST=confirmed crosvm --async-executor correcly switchs the Executor for
`crosvm --async-executor epoll (or uring) device gpu --socket
/tmp/gpu.sock` command. Used additional debug log to tell which executor
is running, which is not commited
Change-Id: Ib310d9edc8ab6005f1b7f210b03668b9a45fa73f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3811014
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Takaya Saeki <takayas@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
V4L2 clients such as FFmpeg goes through a configuration sequence like
the following:
1. Set input format
2. Register input buffers
3. Set output format
4. Register output buffers
Right now, this fails at 3. because the format change is rejected due to
existing registered input buffers. However, none of the encoder
functions are called yet at this point, and a configuration sequence
like above is supposed to work.
Relax the check to allow for compatibility. As noted in code this is an
over-relaxation that might cause unintended behavior if a format change
happens after a ResourceQueue request (which calls encode()), but I'm
not aware of any implementation actually doing that, so this will be a
TODO for the future.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: I199f9ddd30208aa0dd896cd62566cf19a8ce9ccc
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920261
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
The buffer will be allocated by FFmpeg on-demand. This will be used in
encoding scenarios.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: Ie1e83a6a1129ea666bb3580a669beb7c6cbc8c10
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920260
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
For reading out the packet size and flags. We already have AsRef
implementations for AVCodecContext and AVFrame.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: Ie330c1863f989211dcad758cd8df96058dfbc2ea
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920259
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Add setters for time_base, bit_rate and rc_max_rate for use in encoder.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices -p ffmpeg
Change-Id: If006abf5b32cdb740c33075f8d5f480c65c20806
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920258
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
These covers the "writable" notion exposed by FFmpeg. If a non-writable
frame is passed to a codec, the codec will clone the frame before
writing to it. Some interfaces (notably swscale) doesn't respect this
convention yet; for those, we'll add our own checks for writeability so
ideally this copy-on-write convention is held everywhere within our
bindings.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: I566f44a44491a7507bd6446e1bf8e1f8550f16d6
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3920257
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Fixes the following failure:
error[E0659]: `ffmpeg` is ambiguous
--> crosvm/media/ffmpeg/src/lib.rs:11:5
|
11 | use ffmpeg as ffi;
| ^^^^^^ ambiguous name
|
= note: ambiguous because of multiple potential import sources
= note: `ffmpeg` could refer to a crate passed with `--extern`
= help: use `::ffmpeg` to refer to this crate unambiguously
note: `ffmpeg` could also refer to the module defined here
--> crosvm/media/ffmpeg/src/lib.rs:10:1
|
10 | mod ffmpeg;
| ^^^^^^^^^^^
= help: use `crate::ffmpeg` to refer to this module unambiguously
BUG=None
TEST=cargo test -p ffmpeg
Change-Id: I6665bec21336c78cd773593cd0310e996a345e1d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3924262
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Windows' SetWaitableTimer function takes a period argument that is in
milliseconds. If it's set to 0 then the timer will not be periodic. If
the reset function is called with a period that is <1ms but not None, we
should set the period to 1ms which is the best we can do.
Bug: b:248612697
Test: ran kernel with HZ=1000 on Windows, verified PIT works
Change-Id: Ie908205a455c818bad5b246da54b504eb9ce7b27
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3926198
Commit-Queue: Colin Downs-Razouk <colindr@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Vikram Auradkar <auradkar@google.com>
This allows us to enable the feature in upstream builds.
The feature is automatically enabled for the chromeos feature,
so it should be a noop for ChromeOS builds.
BUG=b:244618505
TEST=presubmit / build_packages implicit-system crosvm
Change-Id: I2ea2d668a0f8c2faa92aad5452df0bf660d85e0e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3919815
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
