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>
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>
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>
Fixes crosvm's failure to forward the "use_external_blob"
state flag to the host renderer (virglrenderer).
BUG=b:174794821
TEST=Start a crostini VM and run `DISPLAY=:0 glxgears`, verify graphical
output.
Change-Id: I1ef616079664224e7741cea00b9125c5061ea69d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2574669
Tested-by: Ryan Neph <ryanneph@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Ryan Neph <ryanneph@google.com>
This change adds support for exporting virtio_gpu fences into
virtio_wl.
Without support for sending fences over virtio_wl, ARCVM must wait in
the guest for fences to be signaled before sending the corresponding
buffers to the host compositor. Under normal composition, it is
relatively rare for fences to be unsignaled when they need to be sent
over virtio_wl, although it does still happen at the far tail end. If
ARCVM falls back to client composition, without this change ARCVM needs
to wait on average 5-15ms (depending on how heavyweight the app's
rendering is) for fences to be signaled.
Support for sending fences over virtio_wl allows this extra latency to
be hidden.
BUG=b:136129939
TEST=Run YouTube+Play Store+graphics benchmarks simultaneously
in ARCVM, with and without client composition.
Change-Id: Ic7f57069c4171104c497aee6721c5c93dc6bafa4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2363512
Tested-by: David Stevens <stevensd@chromium.org>
Commit-Queue: David Stevens <stevensd@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This CL transitions most structs to RawDescriptor and the
associated traits if possible.
BUG=b:162363783
TEST=./build_test
Change-Id: Iabae6ac212787836d77de2b9ffb5d451421ab0dd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2530911
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Michael Hoyle <mikehoyle@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
Along with this rename comes updating all usages to the
appropriate RawDescriptor traits. As per usual it touches
many files, but makes no significant changes.
The only remaining instance of "keep_fds" is to call out to
3p lib adhd.
BUG=b:162363783
TEST=./build_test
Change-Id: I6d292cc6404a9f84ffa5bf1320b6545a28842afa
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2488071
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
Tested-by: Michael Hoyle <mikehoyle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
... to allow configuring Gfxstream host renderer based
on whether or not the guest Android is using ANGLE as
its native OpenGL driver.
BUG=b:165022040
TEST=launch_cvd --gpu_mode=gfxstream
Change-Id: I566ed1e7590f7f3db99960440421fd65bba08f7b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2466604
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Jason Macnak <natsu@google.com>
This involves removing RawFd trait implementations from
Event and Timer, and resolving the echoing dependencies from
there.
Ultimately, this results mostly in changes across ioctl
(new thin layer in base), kvm, msg_on_socket, and a few other
areas. As usual, most changes are negligible.
BUG=b:162363783
TEST=./build_test
Change-Id: I47dec94666bc3430fed627b4767919c9cb4fce6f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2462330
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
This is a layer above PollContext with a more generic interface.
As PollContext is used so widely, this is quite a large change
in order to accomodate the interface update, especially with the
use of RawDescriptor. In some cases this has caused an echo
of updates to RawDescriptor, which is fine because of our eventual
goal to move the whole codebase to it regardless.
Note there are a few instances of forcing the RawDescriptor update
chain to stop, ex. ioctl. This is to keep the scope of this CL
concentrated and avoid changing entire other areas.
Note that this CL leaves out a few additional pieces of work:
- The sole usage of EpollContext over PollContext (event_loop),
which poses a bigger challenge for interface changes
- Full PollToken renaming, which is a tiny change turned difficult
due to the unavailability of type aliases for traits.
- Renaming certain methods which have been updated to use
RawDescriptor such as keep_fds. Some have enough dependencies that
they are worth avoiding to keep this CL pointed, but will be
addressed in future CLs to make sure the whole codebase is on the
fd->descriptor train
BUG=b:162363783
TEST=./build_test
Change-Id: Iff2cfe8f90dea55f1388f8e91bdc698e121a8e43
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2455726
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
All virtio devices pass VIRTIO_F_VERSION_1 explicitly. In preparation
for passing additional reserved feature bits, introduce a free function
so that devices only have to worry about device-specific features.
BUG=None
TEST=./build_test
Change-Id: Ifcf309fa010ea518b17b047b0e95e5ad5c7522bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2453558
Reviewed-by: Andrew Walbran <qwandor@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Will Deacon <willdeacon@google.com>
Note the CL size is large entirely due to the rename,
the changes are mostly negligible.
Also making a few small additional changes in sys_util
areas that don't need much attention in base. This includes
typedefing and adding specific imports for areas that don't
require significant interface changes.
BUG=b:162363783
TEST=./build_test
Change-Id: I4a2c9c4cdce7565806ed338e241c6b8c82c855c7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2415180
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
When requested with the --gpu=cache-path=/path arg, crosvm
will pass it to Mesa via env var MESA_GLSL_CACHE_DIR. In
addition, the cache-size will also be passed along if
provided.
BUG=b:168540438
TEST=run with --gpu=cache-path=/tmp,cache-size=50M and
confirm that files are created in /tmp/mesa_shader_cache.
Change-Id: I2525597749d654a65373a723cefeab6cf2be62d7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2415509
Tested-by: John Bates <jbates@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Riley <davidriley@chromium.org>
When switching to async usage of descriptor queues, it is more useful to
consume the offsets and lengths of the descriptor buffers instead of the
buffers mapped as `VolatileSlice`s. Having the offset,length pair and
the guest memory it refers to is enough to initiate async ops.
Async versions of non-offset read/write case aren't possible as using
the existing "seek" offset of the file doesn't make sense with async IO.
Adding the new version modifies the existing API. This is necessary as
now `Reader` and `Writer` own `GuestMemory`, which makes async possible.
TEST=unit tests and new test to exercise the async functions.
Change-Id: I0a5e50694f40217e5d6ac40f5fcb82944a4c117e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2306784
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Not strictly necessary to build gfxstream, but the MemSlot abstraction
was recently introduced and it makes sense to use it everywhere.
BUG=b/153580313
TEST=gfxstream builds
Change-Id: I06c2ca15edd39c553eacf1256dd95c2fc72f67dc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2349394
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Calls to the kvm crate have been replaced by calls to hypervisor and
devices::irqchip. Plugin is unchanged and still KVM-specific.
x86 creates and configures vcpus on the vcpu thread instead of the main
thread.
Code that still depends on kvm or kvm_sys:
- crosvm_plugin, plugin, and protos use kvm and kvm_sys if built with
the plugin feature
- devices::VfioGroup does a kvm_sys ioctl
- devices::irqchip and hypervisor use kvm_sys. hypervisor uses
kvm::Cap and kvm::CpuId internally for now.
BUG=chromium:1077058
TEST=runs es2gears_wayland on kukui
TEST=runs evince on amd64-generic with kernel and split irqchip
TEST=build_test excluding tpm2
TEST=cargo check --features plugin
Change-Id: I0068e34da6a5ff0079b1237be1958933bf12ffe4
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2307711
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Steven Richman <srichman@google.com>
Like gfxstream, virtio_3d can also support non-exportable memory
when run in single-process mode. This is useful for getting
GL4.5/VK on Nvidia, where dma-buf mmap is not supported.
BUG=chromium:924405
TEST=piglit -t arb_buffer_storage
Change-Id: I072803fd414ddd68bcaafc1f17d236680d6aaa67
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2250461
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
This CL takes the global map_request and uses it as an Arc<Mutex<>>
reference in virtio gpu, enabling virtio gpu backends to generate
external library mappings.
The workflow is demonstrated in the gfxstream backend:
1. Guest triggers vkMapMemory on host
2. Host generates a blob id, sends back to guest
3. Guest asks to RESOURCE_CREATE_BLOB with the blob id,
creating a resource id
4. Guest asks to RESOURCE_MAP_BLOB with the resulting resource id
5. Host gets hva, size from the backend using the resource id
6. Host maps hva, size via KVM to the guest pci offset via sending a
ExternalMapping over map_request
7. Guest maps that PCI offset, exposing memory to guest userspace
BUG=b/153580313
TEST=dEQP.vk.memory.*
Change-Id: I242beedab1dcaf9eb08d9797ed10dc993b58abde
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035595
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
For now, this crate simply re-exports all of sys_util, but it will
be updated to provide new interfaces when needed. This is the
first step to making crosvm not directly depend on sys_util, so
that we can make the interface changes we need without fear of
negatively affecting (i.e. completely breaking) other usages
within chromeos.
BUG=b:162363783
TEST=./build_test
Change-Id: I7d0aa3d8a1f66af1c7fee8fd649723ef17027150
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2325168
Tested-by: Michael Hoyle <mikehoyle@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Michael Hoyle <mikehoyle@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Move GuestAddress and GuestMemory to a new crate for VM memory. This
will make separating sys_util and crosvm independent making it easier
to use sys_util functions outside of crosvm.
Change-Id: I12e14948ea85754dfa6267b3a3fb32b77ef6796e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2311251
Auto-Submit: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This was introduced in a CL that did not use it, so it seems to be
unnecessary (maybe copy-pasted from another error enum).
Fixes a clippy warning:
error: variant is never constructed: `Unsupported`
BUG=None
TEST=bin/clippy
Change-Id: Iaccf6c86a5ef9e36efad1053776b6ee2db53a2cd
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2316379
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Needed for syncfd support (transfer doesnt come with fence
import/export)
Needed for address space graphics protocol on virtio-gpu
BUG=b/156130048
Change-Id: If6f55985f04fd8a2862650b2cbd37a3ab816fb90
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2224015
Commit-Queue: Lingfeng Yang <lfy@google.com>
Tested-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Blobs contain explicit metadata about scanout buffers that is
only inferred otherwise. This is useful for possible YUV with
virtio-gpu-2d or compressed 3d formats. The format modifier is
intentionally left out since virtualized KMS can not guarantee
that the host compositor will support a certain modifier at any
particular moment -- this can be queried from virglrenderer if
need be.
BUG=chromium:924405
TEST=compile and test
Change-Id: I3130df18378f40193118b78d03f564b7f5984d67
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2250460
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Add a gpu argument to control whether vulkan support should be enabled
for gfxstream backend. Default to enabled.
BUG=None
TEST=launch_cvd
Change-Id: Icf9b24890f7c0da30f6c64326391037c6df1c853
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2286238
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Mostly to stop using virtio-fs region IDs in virtio-gpu.
From the spec:
"A device may have multiple shared memory regions associated with
it. Each region has a shmid to identify it, the meaning
of which is device-specific."
BUG=chromium:924405
TEST=compile and test
Change-Id: I5b938a1dbe8747812d77384f1781ccc1bd883e9f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2160030
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
The VolatileSlice API changed, but some callers were not updated to
match. Fix them up so that builds with additional features enabled
(e.g. kokoro) pass again.
BUG=None
TEST=cargo test -p disk --features=composite-disk
TEST=docker/wrapped_smoke_test.sh
Change-Id: I97b3cd04549af30b7dc1515245f025d9439669bc
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2216399
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Auto-Submit: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Change VolatileSlice so that it is ABI-compatible with iovec. This
allows us to directly pass in a VolatileSlice for a C function that
expects an iovec without having to create temporaries that convert from
one to the other.
Also change all the parameters from u64 to usize. It's not possible to
address more memory than fits into a usize so having u64 here didn't
really provide much benefit and led to a lot of tedious casting back and
forth all over the place.
BUG=none
TEST=unit tests
Cq-Depend: chromium:2206621
Change-Id: I258f9123c603d9a4c6c5e2d4d10eb4aedf74466d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2203998
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
All 3 different virtio gpu backends share the same process of creating
the GpuDisplay instance, so move that process out of their separate
build functions and put it in the shared BackendKind build function.
BUG=None
TEST=build_test
Change-Id: Ie15bae48c8f1b75df49ba066a677020ec5dbf744
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2182041
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Simple refactor of PCI device addressing to use
PciAddress type providing bus:device.function number.
BUG=None
TEST=build_test & tast run crostini.Sanity
Change-Id: I7755ad6b31aa8c882475cd8212630e1cc86ef49e
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2172766
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
* Remove RESOURCE_V2_UNREF
* Add RESOURCE_MAP/RESOURCE_UNMAP to enable resources without guest
storage that don't need to be mapped directly either
BUG=chromium:924405
TEST=compile and test
Change-Id: I10d6cd120d86131fa7ed8917ddad25cdb99ae50c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2015587
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Auto-Submit: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Rebase of zero-copy virtio-gpu flow:
* Removes guest_memory_type/guest_caching_type in favor of a bitmask
* Removes ALLOCATION_METADATA, since ideally we'd just read from
guest memory to get guest responses
* Renames HOST_COHERENT to HOST_VISIBLE
* Adds a few more feature flags
BUG=chromium:924405
TEST=compile
Change-Id: I0d5a84b66cfa6d09f7e2d07ed8e761e7ba850284
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2013767
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Transfer plane offsets and strides for exported GPU resource over resource
bridge as well as a resource itself.
These metadata will be required by virtio-video decoder and encoder.
BUG=b:120456557
TEST=Start ARCVM on atlas
Change-Id: Iaf539857c0f8525bd5be294521e75ad32cae05e7
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1787032
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-by: David Stevens <stevensd@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: Keiichi Watanabe <keiichiw@chromium.org>
Previously, all input events in CrosVM were required to be linux
input_events, which have a timestamp field that is actually unused by
when we send/receive from the guest which are of type
virtio_input_event. This CL allows CrosVM to understand both types of input
events in a first class manner. It is a follow up on
https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1930405.
This CL also addresses some bugs with window driven input:
1. attach_event_device was being called before the surface was
created, so the devices were never attached.
2. The default touchpad size was not being set to the display window
size.
Additionally, it removes the unused event "filter" feature on event
sources.
Breaking change: from this point forward, CrosVM will treat input events sent
via a socket (e.g. SocketEventSource) to be virtio_input_events.
BUG=None
TEST=builds + manual
Change-Id: I7fec07c582e5a071a6f116975ba70d6e621bb483
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034046
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Adds a new backend type, gfxstream, that calls out to a C library
implementing the actual rendering.
The purpose is to allow the Cuttlefish and Android Studio Emulator teams
to use crosvm with the current API-forwarding style of rendering
employed in the Android Studio Emulator.
Also, introduces a new key to the --gpu command line interface,
backend=, which selects from different backends. Note that the previous
behavior is now deprecated and will be removed after some time
(when all clients switch over to backend=).
The gfxstream backend itself implements a subset of 3d-related resource
and context creation/transfer/execbuffer commands. Their meaning is
specific to the way in which they are interpreted in the backend
library.
To interface with display, gfx stream backend takes a callback that is
run on guest vsync. The callback is responsible for repainting the
display's contents. gfx stream provides a callback, get_pixels, that can
be used asynchronously. The asyncness is not taken advantage of
currently but will be useful for cases where the client attached to the
VMM might want to update at a different rate than guest vsync.
The guts of the stream backend library is currently defined here:
https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-master-dev/android-qemu2-glue/emulation/virtio-goldfish-pipe.cpp
The linking of the library is controlled via the feature "gfxstream".
If the feature is turned off, we use a default do-nothing stub impl.
Next steps:
- integrate virtio-gpu-next so as to have host coherent memory for
vulkan
- Figure out low latency command submit/response with SUBMIT_CMD_3DV2
BUG=b:146066070
Change-Id: If647381c15e5459cec85e2325f97e2f0a963b083
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2033305
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Reviewed-by: Jason Macnak <natsu@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Auto-Submit: Lingfeng Yang <lfy@google.com>
Commit-Queue: Zach Reizner <zachr@chromium.org>
When the user specifies the display size through the gpu argument but
not specifies the size of the single touch device, the display size
will be used as the size of these touch devices.
Use default() to initialize the GpuParameters. Allow initialize the
GpuParameters dynamically in the future.
Change-Id: I9fa04f8ff479732370514fbaeb062d737adba319
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2043072
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kaiyi Li <kaiyili@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
... which does not require virglrenderer (or any renderer).
This will allow the Cuttlefish team to use minigbm as its gralloc
implementation when both hardware acceleration is available and
unavailable.
Adds a GPU `Backend` trait with all of the existing methods of the
current backend and converts the existing `Backend` into
`Virtio3DBackend` which implements the new trait.
Adds a `Virtio2DBackend` which creates resources with byte vectors on
the host and implements transfers via the old code from
gpu_buffer/src/lib.rs.
Adds a runtime flag to select between 2D and 3D mode with 3D mode as
the default.
Moves the process_resource_bridge() function to the `Frontend` and
instead expose a export_resource() function on the `Backend` to avoid
some code duplication.
BUG=b:123764798
TEST=build + launch cuttlefish w/ 2D mode (minigbm + custom hwcomposer)
TEST=built + launch cuttlefish w/ 2D mode (minigbm + drm_hwcomposer)
TEST=built + launch cuttlefish w/ 3D mode (minigbm + drm_hwcomposer)
Change-Id: Ie5b7a6f80f7e0da72a910644ba42d2f34b246be8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1993913
Commit-Queue: Jason Macnak <natsu@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
