Resource bridges are not supported on Windows, so we shouldn't try
to add their raw descriptors in Gpu::keep_rds().
Struct Gpu is updated to hold the ResourceBridges struct rather
than the Vec<Tube>.
BUG=b:213149288
TEST=presubmit
Change-Id: I6b71076d17057728b927d93462e3aee29f3ac8af
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911100
Commit-Queue: Pujun Lun <lunpujun@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Hitherto the activation could succeed only once since take() function on
Option "Takes the value out of the option, leaving a None in its place."
Above resulted with crosvm crash in guest suspend/resume scenario when
the activate was called more than once (for the second time snd_data
and stream_source_generators was None).
To overcome above issue use clone for snd_data. For
stream_source_generator the clone can't be
easily used due to missing Clone support for stream_source_generators
embed data types (e.g.
369 | struct AudioBuffer<'a> {
370 | buffer: &'a mut [u8],
| ^^^^^^^^^^^^^^^^^^^^ the trait `Clone` is not implemented for
`&mut [u8]`
and some other). Therefore for stream_source_generator move
create_stream_source_generators from new() to activate.
BUG=b:246728970
TEST=Perform multiple suspend/resume s2idle cycle for borealis VM and
make sure that 1) crosvm doesn't crash anymore 2) audio from borealis VM
is still working after VM suspend/resume cycles.
Change-Id: I8b27042e4cc0e5efb1d92756ac3b71a5a744f705
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3904649
Commit-Queue: Norman Bintang <normanbt@chromium.org>
Reviewed-by: Norman Bintang <normanbt@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Stub the required parts of libcras so that upstream builds with
audio_cras feature
BUG=b:244618503
TEST=cargo build --features audio_cras
Change-Id: I21eb3bcb9a61990740b1419f124401878619481e
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911099
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Vineeth Pillai <vineethrp@google.com>
Builds with audio_cras feature gets the following warning
warning: unreachable pattern
--> src/crosvm/sys/unix/device_helpers.rs:443:9
|
443 | _ => unreachable!(),
| ^
|
= note: `#[warn(unreachable_patterns)]` on by default
This is because the enum is fully matched when audio_cras is enabled.
Make the unreachable conditional based on the audio_cras feature.
TEST=None
BUG=None
Change-Id: I68f9d7e4571e043ba81ceef62ced075415398802
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911098
Commit-Queue: Vineeth Pillai <vineethrp@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
GLES 3.1 is not yet well tested with gfxstream backend on Windows
and we don't enable it by default. We control this via command
line arg for now.
BUG=b:213151426
TEST=presubmit
Change-Id: Ic3f8ac0e10ab988cc7bb4a5ab741ee6542617943
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3911097
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>
This feature is only available on ChromeOS and should live in
the downstream ChromeOS repository.
Note: This change should be reverted with the next ChromeOS merge.
BUG=b:244618505
TEST=None
Change-Id: I33d4e6c5feb4178ebf7cd946ea654dbd20291653
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3907532
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This is to keep consistency with Windows downstream code.
The conversion from ProcessType to EmulatorProcessType is moved to
the metrics crate as it is only used for generating metrics.
BUG=b:213146388
TEST=presubmit
Change-Id: Ia62f76835a1f162dd8bbc9e53fd671968c368473
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3908370
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
The offset field of the VHOST_USER_GET_CONFIG message indicates the
offset within the whole device configuration, not within the buffer in
the message, so offset does not need to be less than size.
BUG=None
TEST=connect fs device with modified read_config() impl
Change-Id: Ifabac14ec087da200a09f41aa3a0041e96cf56f3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3867542
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Abhishek Bhardwaj <abhishekbh@chromium.org>
The wl device specific version of this was identical to VhostUserOption,
which is used for all other vhost-user device types, so just use that
instead.
BUG=None
TEST=tools/presubmit --all
Change-Id: I0d5868b78bc8b84d24e901601a1a9a1037853ee2
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3867539
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
After deserializing a value, do not consume the next character until we
confirm it is the expected delimiter, otherwise the "expected comma"
error will be reported with an extra offset of 1.
TEST=cargo test -p serde_keyvalues
Change-Id: Id3b80a256bfee51eb1125091dcb0114c2e4af226
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3905070
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
`anyhow::context` is more idiomatic way to handle errors than mapping an
error by `map_err(|e| anyhow!(...))`. However, main.rs uses the latter
right now.
This commit rewrites such error handling to the `.context` manner.
Note that this commit does not rewrite all `map_err` because some of
them requires refactoring various functions which return the unit type
as their error like `Result<..., ()>`. Because the unit type does not
implement `std::Error`, we cannot wrap it with `.context`.
BUG=None
TEST=build succeeds
Change-Id: I5829db1ed98bafd3d61a165172a009ab8db29d53
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3831834
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Commit-Queue: Takaya Saeki <takayas@chromium.org>
The previous implementation would silently not flush all buffers if not
enough output buffers were available. It would also unconditionally emit
the FlushCompleted event.
Fix this by retrying the flush whenever new output buffers are
available, and only exiting the flush state when there is nothing left
to flush.
BUG=b:214478588
TEST="cargo test --features=video-decoder,vaapi
virtio::video::decoder::backend::vaapi::tests::test_get_capabilities"
Change-Id: I47402d3e561ca98ba93462f448eb4eb76acd3eee
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3783001
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Some codecs might need to return frames on flush. This is notably the
case on h264, as it has to output the frames in the DPB on flush, but
the current design makes it impossible.
Fix it by changing the signature of flush to allow for possibly
returning frames when flushing. These frames are appended to the ready
queue and outputted as soon as output buffers become available.
BUG=b:214478588 TEST="cargo test --features=video-decoder,vaapi
virtio::video::decoder::backend::vaapi::tests::test_get_capabilities"
Change-Id: Ifd982518bc09cbdd3c32da5409e348a3a2e0b91d
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3783000
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Add tests for a unit type and an untagged enum.
TEST=cargo test -p serde_keyvalue
Change-Id: Ifb840e3270624ef0e54d69b7eba2e631ffcac4e5
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3906752
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
* Fixes a regression where we stopped setting sparseness on Windows
disk images when they were opened.
* Simplifies how disk images are opened. io_concurrency is not
currently used and may be repurposed in a way that won't use the more
complicated code in disk image opening.
BUG=b:247582339
TEST=builds
Change-Id: I25dd71985d512e5d6991a74e4e1b01fa798856a9
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3908372
Commit-Queue: Noah Gold <nkgold@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We want to use this for the encoder too, so move it to a place that can
be accessed from both.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices video
Change-Id: I5f880a9907d0750249d50a8b36f8431f180c31a4
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3889332
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
We want to share this module between the encoder and decoder, so as a
prerequisite remove the test's dependency on decoder features by making
a test-local copy of the struct.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p devices video
Change-Id: I09726e2da823994d4a9000bb23a8f5dbed4fdbca
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3889331
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
We never checked that the "hidden" and "refresh_rate" members are
properly set.
TEST=cargo test --features "gpu" parse_gpu
Change-Id: Ieb695cd19729c73c7e65a292f5575983473ea687
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3906751
Reviewed-by: Pujun Lun <lunpujun@google.com>
Commit-Queue: Alexandre Courbot <acourbot@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
To enable this feature, we copy the required proto file from
ChromeOS. Not a great solution, but better than leaving the
code uncompiled in upstream.
We could consider downloading the file from gitilies with
a fixed sha that is manually upreved. But unfortunately
downloading things in build.rs is not trivial without adding
a ton of dependencies for the reqwest crate.
BUG=b:244619797
TEST=presubmit
Change-Id: I401917134471909be80a281454bc64dd27799afe
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3907373
Auto-Submit: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Most of these are artifacts of previous developer tools or infra.
BUG=None
TEST=None
Change-Id: Iff379ec786e85c3ea2e89ae3c6100fa2de9422d3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3905069
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Now that the libdrm linker issues are fixed, we can enable wl-dmabuf
testing in CI.
BUG=b:244618790
TEST=tools/dev_container tools/presubmit --all
Change-Id: Id4d3e979ab357518ad8804fde373345bb5a38c37
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3905093
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
If the -ldrm option is added before the virglrenderer library in the
linker command line, the libdrm symbols will not be available, since
they aren't used and will be dropped by the linker. Move the
virglrenderer deps into a helper function to avoid duplication and call
it after the virglrenderer build to get the linker options in the right
order.
BUG=b:244618790
TEST=tools/dev_container tools/presubmit --all # with wl-dmabuf feature
Change-Id: I55cc96a28a1f02e7b6081d3cfa08bc3446b8e6a1
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3905092
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Changes how unit tests are executed. Instead of running all tests on
a selected target (i.e. host or a VM), we will select a platform to test
and run_tests will use a separate target for unit tests than for
integration tests.
e.g. instead of running all tests in the aarch64 vm:
./tools/run_tests --target=vm:aarch64
We can now run
./tools/run_tests --platform=aarch64
to run unit tests via user-space emulation on the host, and only
integration tests on the VM.
This will eventually apply to x86 testing as well, so tests can be
run in an unprivileged environment (e.g. podman).
A new TestOption has been added to mark unit tests that have system
interactions that require them to be run like integration tests in a VM.
These should be fixed.
You can also use --unit-tests and --integration-tests to run just one
type of tests. Running unit tests only takes a few seconds on most
platforms since we can use user-space emulation.
BUG=b:247139912
TEST=./tools/run_tests
./tools/run_tests -p aarch64
./tools/run_tests -p mingw64
./tools/run_tests -p armhf
Change-Id: Icd0c502623f1889906d199e752b3eccb7de76dc0
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3902688
Reviewed-by: Zihan Chen <zihanchen@google.com>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
The decoder and encoder uses different calls for flushing. Add a new
flush_encoder helper for that, and rename the existing one to
flush_decoder.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: Id237424209dc8d64d43424570003d735ee164d36
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868598
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Commit-Queue: Tatsuyuki Ishi <ishitatsuyuki@google.com>
try_send_frame and try_receive_packet together forms the basis of the
(AVFrame-based) encoding API. This change adds helper methods for them,
with the return value being handled similarly to their decoding
counterpart.
TryReceiveFrameResult has been renamed to TryReceiveResult as the
encoding interface shares the handling of these return codes, and we'll
be sharing this logic between try_receive_packet and try_receive_frame.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: I32c11053daed86c32067ac2b2a8f7218f6dbcd4f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868597
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
This API allows the user to allocate and set the buffer/data of an AvFrame.
This will be needed when using AvFrame as encoder input.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: If2c46a1b19f5fb98a296ca42b1917f8260174c83
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868596
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
These are wrappers of av_image_get_linesize and
av_image_fill_plane_sizes, and will be used for bounds checking and
mmap bounds calculation purposes.
It's kind of weird that one is singular and the other is plural, but
we should probably blame FFmpeg for not having a singular version of
av_image_fill_plane_sizes.
BUG=b:239897269
TEST=cargo test --features "video-decoder,ffmpeg" -p ffmpeg -p devices
Change-Id: I34104f5062089377aeab0d4a4ab0534837e56d6f
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3868595
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Similar to the decoder builder, add an encoder context builder.
The encoder requires a few more parameters to be set before calling
avcodec2_open, and the respective setters are provided here. As for
checking for the required fields, it looks like FFmpeg will check it and
error on avcodec2_open if any are missing anyway, so we'll avoid
duplicating that on the binding side.
BUG=b:239897269
TEST=cargo build --features ffmpeg -p ffmpeg
Change-Id: I448b56ba9bae9b38ce5c2fb540e9577a2dfcd83c
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3856043
Reviewed-by: Alexandre Courbot <acourbot@chromium.org>
Move the logic for locking and DiskFile creation into an implementation
of DiskOption::open(), matching the sys::unix structure. This will
allow future consolidation of the vhost-user devices.
For now, the Windows variant of DiskOption::open() only knows how to
create a SingleFileDisk (not qcow, composite, etc.); switching to
create_disk_file() is left as future work.
This also makes a few tweaks to the creation of the BlockAsync instance
in order to make the unix and windows versions more similar - compare:
- devices/src/virtio/vhost/user/device/block/sys/windows.rs
- devices/src/virtio/vhost/user/device/block/sys/unix.rs
No functional change intended.
BUG=None
TEST=tools/presubmit --all
Change-Id: Iadb1a8913a7445d7c091d0e359c7d8792704c35a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3892136
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Noah Gold <nkgold@google.com>
- Check if ssh port is available before starting VM
- Move data dir to /tmp. Otherwise we may delete running images
or pid files with `cargo clean`.
- Change CPU type to prevent vmx warnings.
BUG=247139912
TEST=./tools/run_tests --target=vm:x86_64
Change-Id: Id948ab9d67b2dddce8da663bb00b8924bc26c041
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3902687
Commit-Queue: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Zihan Chen <zihanchen@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
We've seen third-party DLLs hooking into CreateWindowExA and
causing stack overflow (b:202288586, b:244141583). Adding the
offending DLLs to the blocklist fixed the issue, but it is hard
to know what other DLLs would cause the same issue in the wild.
Hence, we want to spawn WindowProcedureThread and create
windows as early as possible and then pass them all the way
down to GpuDisplay.
We are also passing the kiwi specific gpu_device_service_tube
along the stack.
BUG=b:213150276
TEST=presubmit
Change-Id: Ib1e3a4f11523ea36ede74c99f401c23a8c94a2c3
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3892519
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Explicitly drop the device object before calling libc::exit() so that
the Drop impl for the device has a chance to be called.
Change-Id: Id93447925f71340c78a1d80efdff5b1574801409
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3900327
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Describe the resample event and how it is meant to be used by a device.
BUG=b:243465984
TEST=tools/cargo-doc
Change-Id: I0a2ad7b5593e0222e69c932fed20499f6d2fccbf
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3892525
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
This reverts commit 84e4fbc2be.
Reason for revert: cts regression in b/247131923
Original change's description:
> rutabaga_gfx: Support for cached mappings on msm
>
> This is a stop gap solution until we have some way for the kernel to
> report mapping info to crosvm. But since on arm devices without FWB,
> the mapping attributes are the more restrictive of the S1 and S2
> mappings, for now we can just map them as cached in the S2 pgtables.
>
> BUG=b:239718180
> TEST=cts-tradefed run cts -m CtsVideoTestCases -t android.video.cts.VideoEncoderDecoderTest#testAvcGoog0Perf0320x0240
>
> Change-Id: Ib3f085fd8da768b58e7a6d8deadf3a16c7cbcc4c
> Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3832355
> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
> Auto-Submit: Rob Clark <robdclark@chromium.org>
> Commit-Queue: Rob Clark <robdclark@chromium.org>
> Tested-by: Rob Clark <robdclark@chromium.org>
BUG=b:247131923
TEST=BasicVulkanGpuTest
Change-Id: I6566ab033840a5f9bd99dca7cbecfc1f42a5c363
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3903099
Commit-Queue: Yiwei Zhang <zzyiwei@chromium.org>
Auto-Submit: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
StreamInfo unit tests leave the stream in an arbitrary state after
finish testing. Some streams have spawned a worker in `prepare()`, but
haven't released the worker in `release()`. These are reported as
memory leaks.
Implement drop on StreamInfo to release the stream if the end state is
PREPARE, START, or STOP.
BUG=b:242021318
TEST=1. `setup_board --board=amd64-generic --profile=asan`
2. `build_packages --board=amd64-generic crosvm`
3. `FEATURES=test emerge-amd64-generic crosvm`
Change-Id: I8cb7a25b61bfacdfcda4c7ba06ed2ab2b6a4ea40
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3901569
Commit-Queue: Pattara Teerapong <pteerapong@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
On Windows, we have to create a GUI thread that creates the window and
retrieves window messages from the thread-specific message queue created
by the system. All host events, such as window resizing and mouse and
keyboard events, are sent in the form of window messages. Hence, we
created these structs/traits to model it:
- `Window`: Owns the handle of one window, and provides helper functions
for operating on this window.
- `HandleWindowMessage`: A trait implemented by the struct that
processes host events. In our case, that is the surface.
- `WindowMessageProcessor`: Holds one `Window` object and one
`HandleWindowMessage` trait object. We only support one window for
now. Once we support multi-windowing, there will be multiple
processors.
- `WindowMessageDispatcher`: A singleton, responsible for dispatching
messages retrieved from the message queue to the targeted processor.
- `WindowProcedureThread`: Wraps the GUI thread, retrieves messages from
the message queue and forwards them to the dispatcher. It also
provides helper functions for other threads to talk to the GUI thread.
- `MessageRelayThread`: Relays service messages to the GUI thread.
Main difference from other platforms: event devices are imported to the
GUI thread, since all host events are processed there.
BUG=b:213150276
TEST=presubmit
Change-Id: I0aabf6adf8a9ff4b24375e9c7df7625b6f761c7a
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3834009
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Pujun Lun <lunpujun@google.com>
Virglrenderer must not unmap from any thread other than the virtio-gpu
thread because virglrenderer is not thread-safe and EGL requires that
only one thread own a context concurrently.
For the VirglRenderer RutabagaComponent, we can unmap directly from the
virtio-gpu thread. In fact, we can greatly simplify the use of
ExternalMapping if we eliminate the associated map/unmap callbacks for
all RutabagaComponents.
Now VirtioGpu is responsible for ensuring that the map/unmap occurs and
is registered/unregistered. Also, the shared `map_request:
Arc<Mutex<ExternalMapping>>` spanning the KVM and virtio-gpu threads is
no longer necessary.
BUG=b:244626679
TEST=OpenGL and Vulkan gameplay with sandboxing disabled
TEST=OpenGL and Vulkan gameplay on ChromeOS with sandboxing
Change-Id: I4acaf4aabff3891536ca0439221cfbd021dba123
Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/3888602
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
