[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [QEMU PATCH v5 09/13] virtio-gpu: Handle resource blob commands



On Wed, Sep 20, 2023 at 01:54:03PM +0800, Akihiko Odaki wrote:
> On 2023/09/20 14:50, Huang Rui wrote:
> > On Sat, Sep 16, 2023 at 12:37:29AM +0800, Akihiko Odaki wrote:
> >> On 2023/09/16 1:04, Akihiko Odaki wrote:
> >>> On 2023/09/15 20:11, Huang Rui wrote:
> >>>> From: Antonio Caggiano <antonio.caggiano@xxxxxxxxxxxxx>
> >>>>
> >>>> Support BLOB resources creation, mapping and unmapping by calling the
> >>>> new stable virglrenderer 0.10 interface. Only enabled when available and
> >>>> via the blob config. E.g. -device virtio-vga-gl,blob=true
> >>>>
> >>>> Signed-off-by: Antonio Caggiano <antonio.caggiano@xxxxxxxxxxxxx>
> >>>> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx>
> >>>> Signed-off-by: Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>
> >>>> Signed-off-by: Huang Rui <ray.huang@xxxxxxx>
> >>>> ---
> >>>>
> >>>> V4 -> V5:
> >>>>       - Use memory_region_init_ram_ptr() instead of
> >>>>         memory_region_init_ram_device_ptr() (Akihiko)
> >>>>
> >>>>    hw/display/virtio-gpu-virgl.c  | 213 +++++++++++++++++++++++++++++++++
> >>>>    hw/display/virtio-gpu.c        |   4 +-
> >>>>    include/hw/virtio/virtio-gpu.h |   5 +
> >>>>    meson.build                    |   4 +
> >>>>    4 files changed, 225 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/hw/display/virtio-gpu-virgl.c
> >>>> b/hw/display/virtio-gpu-virgl.c
> >>>> index 312953ec16..563a6f2f58 100644
> >>>> --- a/hw/display/virtio-gpu-virgl.c
> >>>> +++ b/hw/display/virtio-gpu-virgl.c
> >>>> @@ -17,6 +17,7 @@
> >>>>    #include "trace.h"
> >>>>    #include "hw/virtio/virtio.h"
> >>>>    #include "hw/virtio/virtio-gpu.h"
> >>>> +#include "hw/virtio/virtio-gpu-bswap.h"
> >>>>    #include "ui/egl-helpers.h"
> >>>> @@ -78,9 +79,24 @@ static void virgl_cmd_create_resource_3d(VirtIOGPU *g,
> >>>>        virgl_renderer_resource_create(&args, NULL, 0);
> >>>>    }
> >>>> +static void virgl_resource_destroy(VirtIOGPU *g,
> >>>> +                                   struct virtio_gpu_simple_resource
> >>>> *res)
> >>>> +{
> >>>> +    if (!res)
> >>>> +        return;
> >>>> +
> >>>> +    QTAILQ_REMOVE(&g->reslist, res, next);
> >>>> +
> >>>> +    virtio_gpu_cleanup_mapping_iov(g, res->iov, res->iov_cnt);
> >>>> +    g_free(res->addrs);
> >>>> +
> >>>> +    g_free(res);
> >>>> +}
> >>>> +
> >>>>    static void virgl_cmd_resource_unref(VirtIOGPU *g,
> >>>>                                         struct virtio_gpu_ctrl_command
> >>>> *cmd)
> >>>>    {
> >>>> +    struct virtio_gpu_simple_resource *res;
> >>>>        struct virtio_gpu_resource_unref unref;
> >>>>        struct iovec *res_iovs = NULL;
> >>>>        int num_iovs = 0;
> >>>> @@ -88,13 +104,22 @@ static void virgl_cmd_resource_unref(VirtIOGPU *g,
> >>>>        VIRTIO_GPU_FILL_CMD(unref);
> >>>>        trace_virtio_gpu_cmd_res_unref(unref.resource_id);
> >>>> +    res = virtio_gpu_find_resource(g, unref.resource_id);
> >>>> +
> >>>>        virgl_renderer_resource_detach_iov(unref.resource_id,
> >>>>                                           &res_iovs,
> >>>>                                           &num_iovs);
> >>>>        if (res_iovs != NULL && num_iovs != 0) {
> >>>>            virtio_gpu_cleanup_mapping_iov(g, res_iovs, num_iovs);
> >>>> +        if (res) {
> >>>> +            res->iov = NULL;
> >>>> +            res->iov_cnt = 0;
> >>>> +        }
> >>>>        }
> >>>> +
> >>>>        virgl_renderer_resource_unref(unref.resource_id);
> >>>> +
> >>>> +    virgl_resource_destroy(g, res);
> >>
> >> This may leak memory region.
> > 
> > The memory region should be freed under virgl_cmd_resource_unmap_blob()
> > which is calling memory_region_del_subregion(&b->hostmem, res->region).
> > Because this region is created by map_blob(). Do we have the case to call
> > virgl_cmd_resource_unref() without calling virgl_cmd_resource_unmap_blob()
> > for blob memory?
> 
> Calling virgl_cmd_resource_unmap_blob() and virgl_cmd_resource_unref() 
> in order is a guest's responsibility, and we are required to prepare for 
> broken guests.

OK, no problem. I will update this in V6.

Thanks,
Ray



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.