- Use new VulkanImageAspect
- Use new vulkano::device::physical namespace
- Replace 'loaded_extensions' with 'enabled_extensions'
- Handle 'device_type' change
- Remove u64 to usize casts for DeviceMemoryBuilder
- Extension name update
BUG=b:189133053
TEST=build
Change-Id: I99d319b3eff534d1c4b93db9d7d64d2a95074d19
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3131446
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Jason Macnak <natsu@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
Tree-wide cleanup of new clippy warning in Rust 1.54 that warns about
needless borrows:
error: this expression borrows a reference (`&...`) that is
immediately dereferenced by the compiler
https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow
BUG=b:197251702
TEST=bin/clippy # with rust-toolchain = 1.54.0
Change-Id: Ib702ec524d4623d264a00ec11dbc2150c411a67b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3108321
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Having both renderers running at the same time can work,
but not without changes. For now, allowing building both
at the same time.
BUG=b:181869105, b:182174209
Test: launch_cvd --gpu_mode=gfxstream
Test: launch_cvd --gpu_mode=virgl_renderer
Change-Id: Ib8a3fd4927401b9f7ebc4a4425a3ddba6621a3e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3092405
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Cathedral enthusiant Victor Hugo once said:
“Nothing else in the world ... not all the armies ... is so
powerful as an idea whose time has come.”
He was talking about republicanism vs. monarchy. My friends,
we are on the verge on a change quite possibly bigger than
that: seamless wayland windowing!!
The revolution started by the virtio_wl device is finally making
it's way to virtio_gpu, bringing best-in-class display
virtualization to a wider audience.
The overall approach is described here:
goto.google.com/virtio-gpu-wayland-context
At it's core, virtio-gpu wayland windowing uses the same mechanisms
that another virtio-gpu consumer (say gfxstream or virglrenderer)
uses to submit an opaque command stream to the host. A response
page is allocated by the guest where host commands are place
(gfxstream has been using this mechanism for years).
There are various tables to track the internal context state and
resources. A thread is spun up to poll the Wayland socket. The
asynchronous callback and upcoming virtio-gpu multiple timelines
feature is used to make 3D consumers (gfxstream, virglrenderer)
don't interfere with the Wayland signalling.
In the future, virtio-gpu may be further modifed to perform
multi-queue virtio in-case the single virtio-queue turns out to be
a bottleneck.
As always, look forward to your feedback & questions.
BUG=b:150239451
TEST=Launch Sublime text + weston-terminal with Sommelier changes
Copy + paste into VM window
Copy + paste out of VM window
Change-Id: Ifb74644cc71a561fd278700d91e4bc66d16107a9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3055850
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
A completed fence callback is set in Rutabaga. When the callback
is executed, the descriptor associated with the fence is immediately
marked as used and the control queue is signalled.
As of now, the callback is still called in the main worker thread
when poll_fence() is executed, but once we enable the async callback
feature in virglrenderer, the callback might be called from another
thread. This is the reason everything is protected with mutexes.
The completed_fences hash map keeps track of the latest completed
fence for each context to avoid any race condition.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Change-Id: I6f3f55d21b7f4722721bdc2b16da1b39bae4ff7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2845984
Reviewed-by: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Dennis Kempin <denniskempin@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
It allows Rutabaga library users to set a fence callback on the
component builder or while creating a context. The handler is
called when a fence is signaled as completed and could
be executed from another thread.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Change-Id: Ia9176bf2f0822a0076bed6a7a09e709b426aa620
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2845982
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
As new features are about to be added, it only makes sense to
improve error handling first.
Also improve/update naming of errors in other GPU-focused areas.
BUG=b:173630595
TEST=compile and run
Change-Id: If0d4f8b7d548c46f0a15b64699502e0fefeaae3e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2844350
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
In multi-process mode, we currently rely on dma-buf mmap() to
map GPU buffers into the guest. We usually have to fix the
Mesa driver, and maybe even the kernel to get to work. That's
"kind of" fine for ChromeOS, which owns the entire stack.
For their Virtual Graphics Interface (VGI) initiative, Android
upstream has requested multi-process mode to work in a
cross-platform, generic way. Using Vulkan is the only option
that meets the rigorous, uncompromising, strict, meticulous and
bone-crushing requirements of Android upstream.
This has possible two benefits:
1) We can enable multi-process mode on Nvidia or other
closed-source drivers, which is nice for Cuttlefish.
2) On open-source drivers, dma-buf memory is pinned to the
GTT (amdgpu), even when ideally it can be moved into faster
vram regions. This atleast gives the implementation the
chance to do the smarter and faster option.
We shouldn't run into any SELinux issues since the main crosvm
process is not sandboxed.
Incidentals:
* Changes vulkano_gralloc to consider integrated GPUs and dGPUs.
Metadata query is preferred done on the integrated GPU.
* Update vulkano_gralloc to match top of tree vulkano.
BUG=b:173630595
TEST=used Vulkano allocator and mapped memory into the guest
Change-Id: I78b069c7478d11b3201397894dcccd13bdc61f2c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2792042
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This patch adds support for creating udmabufs via a guest provided
sg-list. Ideally, we'd create the udmabuf from a virtio-gpu guest
dedicated heap, but that needs further investigation.
In terms of the protocol, these following prototype items are added:
BLOB_CREATE_GUEST_HANDLE: "create an udmabuf" or an OS-specific
equivalent. This can be used with the guest dedicated heap or system
memory. Right now, only system memory is used.
We also want to associate the udmabuf with any host side metadata. For
example, SET_SCANOUT_BLOB doesn't passthrough the modifiers since
virtio-gpu KMS + modifiers is annoying. Simple solution: just ask the
host for the modifier. This could also enable different caching types
if the guest blob is mappable (for example, the MSM GPU driver currently
only supports WC mappings. We might also want cached mappings for
camera).
Incidentals:
* Add a placeholder for RESOURCE_SYNC
BUG=chromium:892806, b:173630595
TEST=create a bunch of udmabufs from the guest
Change-Id: I4686d9f48938f10e7c265750a931d7d2d2d9611b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2786291
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
To be truly OS-agnostic, we need an OS-agnostic Rust wrapper over
the OS-specific handle type. SafeDescriptor seems to be the best
option, and I hope it on crates.io in the future.
This converts virtio_gpu/rutabaga to use the SafeDescriptor handle
when practical. minigbm still uses File in some places, since it
needs to SeekFrom(..), but minigbm is a Linux only thing anyways.
BUG=b:173630595
TEST=boot VM in 2D/3D mode
Change-Id: I18d735844d479f52d82d7976bf9b4e383b2e2252
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2779492
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Michael Hoyle <mikehoyle@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Some judgement calls were made about unnecessary wrapping. Usually they
would get resolved by removing the wrapping or returning a convenient
error, but the ones that returned results for consistency with other
functions were added to the allow list.
The error handling in the usb code had a lot of unit error types which
is now a clippy lint. This was resolved by either removing the result
entirely or returning a convenient error.
The field_reassign_with_default lint is faulty and was added to the list
of supressions. This affected virtio-wayland code.
BUG=b:179277332
TEST=cargo clippy with rustc 1.50+
Change-Id: Ie812cdeaf7c42f4f2b47b1dc87f05a7c87a60f8f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2757510
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Commit-Queue: Dennis Kempin <denniskempin@google.com>
This change is to cleanup some dead_code warnings that appear if certain
features aren't enabled.
This also updates the Cargo.lock when changed due to zeroize being added
to libchromeos-rs.
TEST=cargo check --all-features
BUG=None
Change-Id: I5347b584a7426dc37f3933b1e907b23a71145749
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2753128
Reviewed-by: Allen Webb <allenwebb@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
This is the original CL with one minor exception: we don't bind
mount the camera socket with the GPU device. That was the prior
behavior, and for some reason it really doesn't work with Mali +
SECCOMP[1]. It's not really important for the Wayland prototype,
so we'll let the camera team figure it out if and when they are
so inclined.
Bug: b:146066070
Bug: b:173630595
Bug: b:150239451
Bug: b:180126126
TEST=arc.Boot.vm
[1] audit(1613339319.226:43): auid=4294967295 uid=603 gid=603
ses=4294967295 subj=u:r:cros_camera_algo:s0 pid=17107
comm="cros_camera_alg" exe="/usr/bin/cros_camera_algo" sig=31
arch=40000028 syscall=54 compat=1 ip=0xe86a70b8 code=0x0
This reverts commit 51e1c4ad3e3a71a263501d2566d3b1ea59ba2070.
Change-Id: I74f49ece55656d7a9096900e3f19a528234b4224
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2695550
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Robert Tarasov <tutankhamen@chromium.org>
This reverts commit a9c4b3a749.
Reason for revert: This made ARCVM fail to boot on kukui-arc-r. See http://b/180126126.
Original change's description:
> rutabaga_gfx: cross-domain: a new year's miracle in February
>
> The cross-domain context is specialized for cross domain
> allocation/resource sharing. It takes direct inspiration from
> the pioneering virtio_wl device and tries to incorporate
> similiar functionality into virtio_gpu.
>
> The goal here is just to introduce the building blocks so we
> can continue experimenting. In particular, this change:
>
> * hooked up the RutabagaChannels. This is typically a socket to
> Wayland or Mojo for the camera use case.
>
> * added CROSS_DOMAIN_CMD_INIT and CROSS_DOMAIN_CMD_GET_IMAGE_REQS
> to the cross-domain protocol. Further commands (such as
> CROSS_DOMAIN_SEND) will be needed, but that requires more
> Sommelier refactorings.
>
> * added a path to RutabagaGralloc to allocate via minigbm or shared
> memory.
>
> * Recieves responses via a shared ring buffer of type BLOB_MEM_GUEST.
> The synchronization protocol looks positively primitive compared to
> the revolutionary Address Space Graphics (ASG) algorithm [1], but
> it may be sufficient for the Wayland use case.
>
> [1] https://goto.google.com/address-space-graphics
>
> BUG=b:146066070, b:173630595, b:150239451
> TEST=launch virtual machine with 2D mode
> TEST=launch virtual machine with 3D mode
> TEST=run sommelier with "wl-dmabuf" and "wl-shm"
>
> Change-Id: I46784f17040494ce3a646bdbde516800aa64bd5d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626488
> Tested-by: kokoro <noreply+kokoro@google.com>
> Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
> Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
> Reviewed-by: Zach Reizner <zachr@chromium.org>
Bug: b:146066070
Bug: b:173630595
Bug: b:150239451
Bug: b:180126126
Change-Id: Ie33442fdcedcf43b6a24d25198fa2d88b5b96919
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2695056
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Hiroki Sato <hirokisato@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Hiroki Sato <hirokisato@chromium.org>
Commit-Queue: Hiroki Sato <hirokisato@chromium.org>
The cross-domain context is specialized for cross domain
allocation/resource sharing. It takes direct inspiration from
the pioneering virtio_wl device and tries to incorporate
similiar functionality into virtio_gpu.
The goal here is just to introduce the building blocks so we
can continue experimenting. In particular, this change:
* hooked up the RutabagaChannels. This is typically a socket to
Wayland or Mojo for the camera use case.
* added CROSS_DOMAIN_CMD_INIT and CROSS_DOMAIN_CMD_GET_IMAGE_REQS
to the cross-domain protocol. Further commands (such as
CROSS_DOMAIN_SEND) will be needed, but that requires more
Sommelier refactorings.
* added a path to RutabagaGralloc to allocate via minigbm or shared
memory.
* Recieves responses via a shared ring buffer of type BLOB_MEM_GUEST.
The synchronization protocol looks positively primitive compared to
the revolutionary Address Space Graphics (ASG) algorithm [1], but
it may be sufficient for the Wayland use case.
[1] https://goto.google.com/address-space-graphics
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=run sommelier with "wl-dmabuf" and "wl-shm"
Change-Id: I46784f17040494ce3a646bdbde516800aa64bd5d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626488
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Should fix the following error:
---- rutabaga_gralloc::gralloc::tests::create_render_target stdout ----
thread 'main' panicked at 'called `Result::unwrap()` on an `Err`
value: Unsupported', rutabaga_gfx/src/rutabaga_gralloc/gralloc.rs:314:64
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
BUG=b:173630595
TEST=cargo test locally
Change-Id: Ieb24166f3975d4d7c99c08a3d0824ee64668c93e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2675231
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
rutabaga_gralloc is a cross-platform, Rust-based buffer
manager.
The rationale for this change is:
1) For the {cross-domain, wayland} context type, we need to
have a good story for the crucial "wl-dmabuf" feature. As
minigbm has been thoroughly tested on ChromeOS and currently
powers the "wl-dmabuf" feature, it only makes sense for us to
have a path to minigbm for the cross-domain prototype. This
will be used by Sommelier.
2) While minigbm allocation works well on Chromebooks, it is
not sufficient for cross-platform purposes. For their Virtual
Graphics Interface (VGI) initiative, Android graphics
virtualization experts have expressed their desire for a Vulkan
based allocator. This will to go alongside cros_gralloc in
minigbm, which is considered by many to be the ""world's
premiere gralloc implementation".
3) Android graphics virtualization experts have expressed their
desire for vkMapMemory(..) to be used when crosvm is in
multi-process mode. Currently, only dma-buf mmap() is supported
for zero-copy blobs in multi-process mode. dma-buf mmap() is not
guaranteed to work on Nvidia (a "must have" for Cuttlefish) or
any other driver for that matter (we *make* it work for ChromeOS).
Possibly only solution: vkMapMemory ;-)
With these goals in mind, here's a summary of the revelant changes:
* Renamed the {gpu_allocator.rs, GpuMemoryAllocator trait} to be
{gralloc.rs, Gralloc trait}.
* Moved all GPU allocation out of the resources crate and into
the rutabaga_gfx crate. This will allow the resources crate to
be focused on managing resources for virtual machines.
* Moved the gpu_buffer crate into the gralloc module in the
rutabaga_gfx crate. The same functionality is now under
"minigbm.rs", "minigbm_bindings.rs" and "rendernode.rs"
* Added an optional dependency on vulkano.rs. vulkano.rs is a safe
Rust wrapper around the Vulkan api [a]. It's emphasis on type
safety makes a good fit for crosvm, though there are other high
quality crates out there (gfx-rs, ash.rs). Though development
has slowed down, it should satisfy goals (2) and (3) quite easily.
* Added a system_gralloc implementation based on memfd. This can be
used when minigbm or Vulkano features are not used, to replicate the
highly useful "wl-shm" feature in Sommelier. Astute observers will
note this can also enable seamless Wayland windowing without GPU
features for Android too. Some minor changes to the base crate were
needed.
* Cut down on the amount of DrmFormats to the subset needed by
Sommelier and cros_gralloc.
* Moved checked arithmetic into it's own file.
* Internally renamed to "wl-dmabuf" feature to be the "minigbm"
feature. This is because "wl-dmabuf" has a dependency on minigbm.
* Small rutabaga_gfx cleanups
[a] https://github.com/vulkano-rs/vulkano/blob/master/DESIGN.md
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=run sommelier with "wl-dmabuf" and "wl-shm"
Change-Id: I693a39cef64cd98e56d843d3c60caa7983d4d6e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2626487
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@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>
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>
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>
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>
rutabaga_gfx is a cross platform, Rust-based, Wayland and
Vulkan-centric Virtual Graphics Interface (VGI).
Apologies for the mega-change, but it was hard to do this piece
by piece.
The rationale for this change is:
1) Android graphics virtualization experts have been proposing
for a VGI for many months (years?). Their goal is to boot
Android anywhere, everywhere.
2) For the {wayland, cross-domain} context type prototype,
it's desirable to create a {wayland, camera} connection at the
appropriate time. Details can be found in the code, though the
RutabagaChannels have yet to be hooked up.
There's a high chance neither effort will work. As such,
rutabaga is just a prototype.
However, even (1) and (2) don't end up working, this
refactor/cleanup by itself makes a ton of sense.
Here's a summary of revelant changes:
* Removed auto-generated {p_defines, p_format, virgl_protocol}.
These files were added for tests when bringing up crosvm-gpu,
and AFAICT these tests are not run. There's actually now a
commit queue for virglrenderer changes and container boot tests
that provides excellent coverage.
* Removed command_buffer.rs. Used only for the previously
mentioned tests. It's quite nice, but couldn't determine the right
place to put it. Maybe data_model? But removed it in the interim.
* Removed {write_from_guest_memory, read_to_volatile}. The same
basic functionality has been moved into {transfer_write,
transfer_read} in Rutabaga.
* Removed VirtioResource, Virtio3DResource, Virtio2DResource,
and VirtioGfxStreamResource in favor of VirtioGpuResource and
RutabagaResource. This leads to less duplication and clearer
separation between external library functions and VMM functions.
* Moved display and hypervisor memory management functions to
virtio_gpu.rs. This is because external components do not interface
with this functionality, and there was a lot of duplication (for example
map/unmap blob).
* Added context management between gfxstream and virglrenderer.
* Added separate gfxstream and virglrenderer flags.
* Clearer naming.
* Added simple implementations for context init and multiple timelines.
These changes have no effect since all Google kernels don't pass the
revelant flags, but are useful for theoretical {wayland, cross-domain}
prototype.
* Unify RESOURCE_CREATE_3D and RESOURCE_CREATE_2D handling.
* Better error handling.
BUG=b:146066070, b:173630595, b:150239451
TEST=launch virtual machine with 2D mode
TEST=launch virtual machine with 3D mode
TEST=boot ARCVM
Change-Id: I240b0c134a3b562cbc65981837a41f6db7767c92
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2522452
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
