[QEMU PATCH v5 00/13] Support blob memory and venus on qemu

Huang Rui posted 13 patches 8 months, 1 week ago
Failed in applying to current master (apply log)
There is a newer version of this series
hw/display/trace-events              |   1 +
hw/display/virtio-gpu-base.c         |   5 +
hw/display/virtio-gpu-pci.c          |  14 ++
hw/display/virtio-gpu-virgl.c        | 272 ++++++++++++++++++++++++++-
hw/display/virtio-gpu.c              |  78 +++++++-
hw/display/virtio-vga.c              |  33 +++-
hw/virtio/virtio-pci.c               |  18 ++
include/hw/virtio/virtio-gpu-bswap.h |  15 ++
include/hw/virtio/virtio-gpu.h       |  24 +++
include/hw/virtio/virtio-pci.h       |   4 +
meson.build                          |  13 ++
softmmu/memory.c                     |   5 +
12 files changed, 458 insertions(+), 24 deletions(-)
[QEMU PATCH v5 00/13] Support blob memory and venus on qemu
Posted by Huang Rui 8 months, 1 week ago
Hi all,

Antonio Caggiano made the venus with QEMU on KVM platform last
September[1]. This series are inherited from his original work to support
the features of context init, hostmem, resource uuid, and blob resources
for venus.
At March of this year, we sent out the V1 version[2] for the review. But
those series are included both xen and virtio gpu. Right now, we would like
to divide into two parts, one is to continue the Antonio's work to upstream
virtio-gpu support for blob memory and venus, and another is to upstream
xen specific patches. This series is focusing on virtio-gpu, so we are
marking as V4 version here to continue Antonio's patches[1]. And we will
send xen specific patches separately, because they are hypervisor specific.
Besides of QEMU, these supports also included virglrenderer[3][4] and
mesa[5][6] as well. Right now, virglrenderer and mesa parts are all
accepted by upstream. In this qemu version, we try to address the concerns
around not proper cleanup during blob resource unmap and unref. Appreciate
it if you have any commments.

[1] https://lore.kernel.org/qemu-devel/20220926142422.22325-1-antonio.caggiano@collabora.com/
[2] V1: https://lore.kernel.org/qemu-devel/20230312092244.451465-1-ray.huang@amd.com
[3] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1068
[4] https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1180
[5] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22108
[6] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23680

Please note the first 4 patches 1 -> 4 are inlcuded in these series because
the series depends on them and not because we want them to be reviewed
since they are already in the process of review through the "rutabaga_gfx +
gfxstream" series.
- https://lore.kernel.org/qemu-devel/20230829003629.410-1-gurchetansingh@chromium.org/

V4: https://lore.kernel.org/qemu-devel/20230831093252.2461282-1-ray.huang@amd.com

Changes from V4 (virtio gpu V4) to V5

- Inverted patch 5 and 6 because we should configure
  HAVE_VIRGL_CONTEXT_INIT firstly.

- Validate owner of memory region to avoid slowing down DMA.

- Use memory_region_init_ram_ptr() instead of
  memory_region_init_ram_device_ptr().

- Adjust sequence to allocate gpu resource before virglrender resource
  creation

- Add virtio migration handling for uuid.

- Send kernel patch to define VIRTIO_GPU_CAPSET_VENUS.
  https://lore.kernel.org/lkml/20230915105918.3763061-1-ray.huang@amd.com/

- Add meson check to make sure unstable APIs defined from 0.9.0.

Changes from V1 to V2 (virtio gpu V4)

- Remove unused #include "hw/virtio/virtio-iommu.h"

- Add a local function, called virgl_resource_destroy(), that is used
  to release a vgpu resource on error paths and in resource_unref.

- Remove virtio_gpu_virgl_resource_unmap from
  virtio_gpu_cleanup_mapping(),
  since this function won't be called on blob resources and also because
  blob resources are unmapped via virgl_cmd_resource_unmap_blob().

- In virgl_cmd_resource_create_blob(), do proper cleanup in error paths
  and move QTAILQ_INSERT_HEAD(&g->reslist, res, next) after the resource
  has been fully initialized.

- Memory region has a different life-cycle from virtio gpu resources
  i.e. cannot be released synchronously along with the vgpu resource.
  So, here the field "region" was changed to a pointer and is allocated
  dynamically when the blob is mapped.
  Also, since the pointer can be used to indicate whether the blob
  is mapped, the explicite field "mapped" was removed.

- In virgl_cmd_resource_map_blob(), add check on the value of
  res->region, to prevent beeing called twice on the same resource.

- Add a patch to enable automatic deallocation of memory regions to resolve
  use-after-free memory corruption with a reference.

References

Demo with Venus:
- https://static.sched.com/hosted_files/xen2023/3f/xen_summit_2023_virtgpu_demo.mp4
QEMU repository:
- https://gitlab.freedesktop.org/rui/qemu-xen/-/commits/upstream-for-virtio-gpu

Thanks,
Ray

Antonio Caggiano (6):
  virtio-gpu: CONTEXT_INIT feature
  virtio-gpu: blob prep
  virtio-gpu: Handle resource blob commands
  virtio-gpu: Resource UUID
  virtio-gpu: Support Venus capset
  virtio-gpu: Initialize Venus

Dmitry Osipenko (1):
  virtio-gpu: Don't require udmabuf when blobs and virgl are enabled

Dr. David Alan Gilbert (1):
  virtio: Add shared memory capability

Gerd Hoffmann (1):
  virtio-gpu: hostmem

Huang Rui (3):
  virtio-gpu: Configure context init for virglrenderer
  virtio-gpu: Support context init feature with virglrenderer
  virtio-gpu: Enable virglrenderer render server flag for venus

Xenia Ragiadakou (1):
  softmmu/memory: enable automatic deallocation of memory regions

 hw/display/trace-events              |   1 +
 hw/display/virtio-gpu-base.c         |   5 +
 hw/display/virtio-gpu-pci.c          |  14 ++
 hw/display/virtio-gpu-virgl.c        | 272 ++++++++++++++++++++++++++-
 hw/display/virtio-gpu.c              |  78 +++++++-
 hw/display/virtio-vga.c              |  33 +++-
 hw/virtio/virtio-pci.c               |  18 ++
 include/hw/virtio/virtio-gpu-bswap.h |  15 ++
 include/hw/virtio/virtio-gpu.h       |  24 +++
 include/hw/virtio/virtio-pci.h       |   4 +
 meson.build                          |  13 ++
 softmmu/memory.c                     |   5 +
 12 files changed, 458 insertions(+), 24 deletions(-)

-- 
2.34.1
Re: [QEMU PATCH v5 00/13] Support blob memory and venus on qemu
Posted by Dmitry Osipenko 7 months, 2 weeks ago
On 9/15/23 14:11, Huang Rui wrote:
> Hi all,
> 
> Antonio Caggiano made the venus with QEMU on KVM platform last
> September[1]. This series are inherited from his original work to support
> the features of context init, hostmem, resource uuid, and blob resources
> for venus.
> At March of this year, we sent out the V1 version[2] for the review. But
> those series are included both xen and virtio gpu. Right now, we would like
> to divide into two parts, one is to continue the Antonio's work to upstream
> virtio-gpu support for blob memory and venus, and another is to upstream
> xen specific patches. This series is focusing on virtio-gpu, so we are
> marking as V4 version here to continue Antonio's patches[1]. And we will
> send xen specific patches separately, because they are hypervisor specific.
> Besides of QEMU, these supports also included virglrenderer[3][4] and
> mesa[5][6] as well. Right now, virglrenderer and mesa parts are all
> accepted by upstream. In this qemu version, we try to address the concerns
> around not proper cleanup during blob resource unmap and unref. Appreciate
> it if you have any commments.

Venus uses blob buffers. In order to display Venus/VK application using
GL display server, the VIRTIO_GPU_CMD_SET_SCANOUT_BLOB must be
supported. Otherwise Venus itself isn't practically useful because you
can't run VK application with a usual Linux DE because Venus will error
out due to the unsupported command.

The VIRTIO_GPU_CMD_SET_SCANOUT_BLOB support needs to be a part of this
series, IMO. Can we add it to the next patchset version?

-- 
Best regards,
Dmitry