Skip to content

venus: Introduce a generic selection for guest-based memory allocations and allow to select it via virgl capset.

Andrew Gazizov requested to merge andrewgazizov/mesa:guest_alloc into main

What does this MR do and why?

This MR refactors the code to make a generic separation for guest-based blob memory allocations and allows the selection of a required allocation type using a new virgl capset.

Background: By default, for generic device memory allocations in Venus used host-based allocation. That means, first happens vnAllocateMemory call that performs memory allocation on the host side, which is visible for the guest. Then, in the guest using obtained handle from vnAllocateMemory, happens creation of guest BO. Such scenario works well for the hypervisors that supports memory injection into the guest address space.

For hypervisors that do not support memory injection (like static mappings), such approach doesn't work. In past, problem was resolved by introducing Guest VRAM, a dedicated memory region from which guest can perform host visible allocations. The order of allocation was changed: first allocated a guest buffer object from guest vram region, then this object was imported as dmabuf to vnAllocateMemory.

Rationale: Further investigation shown that Guest VRAM duplicates existing functionality of Host visible memory in mainline Linux kernel. It's possible to use already existing [1] Host visible shared memory under id VIRTIO_GPU_SHM_ID_HOST_VISIBLE to perform guest-based blob allocations. Main advantage of this approach is that using Host visible memory to perform guest-based blob allocations allows to work with mainline kernel starting from 5.16. Dedicated Guest VRAM requires patching of kernel. Only thing missing, that we don't have a way to say Mesa that we want to perform guest alloc, instead of host alloc in this region.

Therefore, this MR suggests:

  1. Make a generic selection for guest device memory allocations. Currently, Mesa has a condition in code, that instructs to perform guest allocation only when guest vram present. The proposal make it independent from guest vram to allow perform a guest allocations w/o guest vram from Host visible memory supported by mainline Kernel.

  2. Introduce a new capset for virgl to instruct the Mesa on guest side perform all guest allocations from Host visible memory. On host side this capset it enabled when hypervisor does not support host memory injection into the guest address space.

  3. Enable suballocation from guest allocated blobs. Currently it disabled for guest vram case.

Advantages:

  1. Using of Host visible memory to perform guest-based blob allocations allows to work with mainline kernel starting from 5.16. Dedicated Guest VRAM requires patching of mainline kernel and works only with virgl's drm-next-misc kernel. [2]
  2. Avoiding code duplication in Kernel to support guest-based blob allocations.

Related MR to Virglrederer repository: virgl/virglrenderer!1283 (merged)

REFs: [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/virtio/virtgpu_kms.c#L189 [2] https://gitlab.freedesktop.org/virgl/drm-misc-next/-/blob/virtio-gpu-next/drivers/gpu/drm/virtio/virtgpu_kms.c#L200

Edited by Andrew Gazizov

Merge request reports