Hi all,
Sorry to late for V6, I was occupied by other stuff last two months, and
right now resume the submission.
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
V5: https://lore.kernel.org/qemu-devel/20230915111130.24064-1-ray.huang@amd.com
Changes from V5 to V6
- Move macros configurations under virgl.found() and rename
HAVE_VIRGL_CONTEXT_CREATE_WITH_FLAGS.
- Handle the case while context_init is disabled.
- Enable context_init by default.
- Move virtio_gpu_virgl_resource_unmap() into
virgl_cmd_resource_unmap_blob().
- Introduce new struct virgl_gpu_resource to store virgl specific members.
- Remove erro handling of g_new0, because glib will abort() on OOM.
- Set resource uuid as option.
- Implement optional subsection of vmstate_virtio_gpu_resource_uuid_state
for virtio live migration.
- Use g_int_hash/g_int_equal instead of the default
- Add scanout_blob function for virtio-gpu-virgl
- Resolve the memory leak on virtio-gpu-virgl
- Remove the unstable API flags check because virglrenderer is already 1.0
- Squash the render server flag support into "Initialize Venus"
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 (4):
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
Huang Rui (4):
linux-headers: Update to kernel headers to add venus capset
virtio-gpu: Configure new feature flag context_create_with_flags for
virglrenderer
virtio-gpu: Support context init feature with virglrenderer
virtio-gpu: Introduce virgl_gpu_resource structure
Robert Beckett (1):
virtio-gpu: make blob scanout use dmabuf fd
Xenia Ragiadakou (1):
softmmu/memory: enable automatic deallocation of memory regions
hw/display/trace-events | 1 +
hw/display/virtio-gpu-base.c | 4 +
hw/display/virtio-gpu-virgl.c | 495 ++++++++++++++++++--
hw/display/virtio-gpu.c | 132 +++++-
include/hw/virtio/virtio-gpu.h | 13 +
include/standard-headers/linux/virtio_gpu.h | 2 +
meson.build | 8 +
system/memory.c | 2 +
8 files changed, 627 insertions(+), 30 deletions(-)
--
2.25.1