xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Kim, Dongwon" <dongwon.kim@intel.com>
To: <xen-devel@lists.xenproject.org>
Subject: Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend
Date: Fri, 30 Jun 2023 09:18:18 -0700	[thread overview]
Message-ID: <5edb57f9-4c11-270b-a9de-c176ec1875fd@intel.com> (raw)
In-Reply-To: <BL1PR12MB584957276B8CD25F6E35DD61E72AA@BL1PR12MB5849.namprd12.prod.outlook.com>

Hi,

On 6/30/2023 12:14 AM, Chen, Jiqian wrote:
> Hi Dongwon,
>
> On 2023/6/30 00:53, Kim, Dongwon wrote:
>> This method - letting QEMU not remove resources would work on S3 case but with S4, the QEMU would lose all the resources anyway as the process will be terminated. So objects restoring was only option for us as
> My patch is for S3 function on Xen. I haven't tried S4 before, I will try S4 later.

I understand s3 is your priority but this code path will be executed for 
s4 as well, so I think we should make sure s4 is covered as well.

>> in [RFC PATCH 2/2] drm/virtio: restore virtio_gpu_objects upon suspend and resume (lists.freedesktop.org) <https://lists.freedesktop.org/archives/dri-devel/2022-September/373894.html>
>>
>> But I only considered and tested cases with scanout blob resources, so this may not cover other resource types...
> I tried your patch, but I can't success to resume guest and guest crashed.
Hmm, probably due to some difference in the setting. Are you using blob 
guest scanout (sharing display by sharing scatter-gather list of the 
buffer for zero copy)? We may have to debug it little bit. Anyway, the 
patch I shared is based on "recovery" instead of forcing QEMU to keep 
the resources. I think this is only way to cover both S3 and S4. Why 
don't we have some time to look into this path as well?
>> On 6/7/2023 7:56 PM, Jiqian Chen wrote:
>>> After suspending and resuming guest VM, you will get
>>> a black screen, and the display can't come back.
>>>
>>> This is because when guest did suspending, it called
>>> into qemu to call virtio_gpu_gl_reset. In function
>>> virtio_gpu_gl_reset, it destroyed resources and reset
>>> renderer, which were used for display. As a result,
>>> guest's screen can't come back to the time when it was
>>> suspended and only showed black.
>>>
>>> So, this patch adds a new ctrl message
>>> VIRTIO_GPU_CMD_STATUS_FREEZING to get notification from
>>> guest. If guest is during suspending, it sets freezing
>>> status of virtgpu to true, this will prevent destroying
>>> resources and resetting renderer when guest calls into
>>> virtio_gpu_gl_reset. If guest is during resuming, it sets
>>> freezing to false, and then virtio_gpu_gl_reset will keep
>>> its origin actions and has no other impaction.
>>>
>>> Signed-off-by: Jiqian Chen <Jiqian.Chen@amd.com>
>>> ---
>>>    hw/display/virtio-gpu-gl.c                  |  9 ++++++-
>>>    hw/display/virtio-gpu-virgl.c               |  3 +++
>>>    hw/display/virtio-gpu.c                     | 26 +++++++++++++++++++--
>>>    include/hw/virtio/virtio-gpu.h              |  3 +++
>>>    include/standard-headers/linux/virtio_gpu.h |  9 +++++++
>>>    5 files changed, 47 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/hw/display/virtio-gpu-gl.c b/hw/display/virtio-gpu-gl.c
>>> index e06be60dfb..e11ad233eb 100644
>>> --- a/hw/display/virtio-gpu-gl.c
>>> +++ b/hw/display/virtio-gpu-gl.c
>>> @@ -100,7 +100,14 @@ static void virtio_gpu_gl_reset(VirtIODevice *vdev)
>>>         */
>>>        if (gl->renderer_inited && !gl->renderer_reset) {
>>>            virtio_gpu_virgl_reset_scanout(g);
>>> -        gl->renderer_reset = true;
>>> +        /*
>>> +         * If guest is suspending, we shouldn't reset renderer,
>>> +         * otherwise, the display can't come back to the time when
>>> +         * it was suspended after guest resumed.
>>> +         */
>>> +        if (!g->freezing) {
>>> +            gl->renderer_reset = true;
>>> +        }
>>>        }
>>>    }
>>>    diff --git a/hw/display/virtio-gpu-virgl.c b/hw/display/virtio-gpu-virgl.c
>>> index 73cb92c8d5..183ec92d53 100644
>>> --- a/hw/display/virtio-gpu-virgl.c
>>> +++ b/hw/display/virtio-gpu-virgl.c
>>> @@ -464,6 +464,9 @@ void virtio_gpu_virgl_process_cmd(VirtIOGPU *g,
>>>        case VIRTIO_GPU_CMD_GET_EDID:
>>>            virtio_gpu_get_edid(g, cmd);
>>>            break;
>>> +    case VIRTIO_GPU_CMD_STATUS_FREEZING:
>>> +        virtio_gpu_cmd_status_freezing(g, cmd);
>>> +        break;
>>>        default:
>>>            cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
>>>            break;
>>> diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
>>> index 5e15c79b94..8f235d7848 100644
>>> --- a/hw/display/virtio-gpu.c
>>> +++ b/hw/display/virtio-gpu.c
>>> @@ -373,6 +373,16 @@ static void virtio_gpu_resource_create_blob(VirtIOGPU *g,
>>>        QTAILQ_INSERT_HEAD(&g->reslist, res, next);
>>>    }
>>>    +void virtio_gpu_cmd_status_freezing(VirtIOGPU *g,
>>> +                         struct virtio_gpu_ctrl_command *cmd)
>>> +{
>>> +    struct virtio_gpu_status_freezing sf;
>>> +
>>> +    VIRTIO_GPU_FILL_CMD(sf);
>>> +    virtio_gpu_bswap_32(&sf, sizeof(sf));
>>> +    g->freezing = sf.freezing;
>>> +}
>>> +
>>>    static void virtio_gpu_disable_scanout(VirtIOGPU *g, int scanout_id)
>>>    {
>>>        struct virtio_gpu_scanout *scanout = &g->parent_obj.scanout[scanout_id];
>>> @@ -986,6 +996,9 @@ void virtio_gpu_simple_process_cmd(VirtIOGPU *g,
>>>        case VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING:
>>>            virtio_gpu_resource_detach_backing(g, cmd);
>>>            break;
>>> +    case VIRTIO_GPU_CMD_STATUS_FREEZING:
>>> +        virtio_gpu_cmd_status_freezing(g, cmd);
>>> +        break;
>>>        default:
>>>            cmd->error = VIRTIO_GPU_RESP_ERR_UNSPEC;
>>>            break;
>>> @@ -1344,6 +1357,8 @@ void virtio_gpu_device_realize(DeviceState *qdev, Error **errp)
>>>        QTAILQ_INIT(&g->reslist);
>>>        QTAILQ_INIT(&g->cmdq);
>>>        QTAILQ_INIT(&g->fenceq);
>>> +
>>> +    g->freezing = false;
>>>    }
>>>      void virtio_gpu_reset(VirtIODevice *vdev)
>>> @@ -1352,8 +1367,15 @@ void virtio_gpu_reset(VirtIODevice *vdev)
>>>        struct virtio_gpu_simple_resource *res, *tmp;
>>>        struct virtio_gpu_ctrl_command *cmd;
>>>    -    QTAILQ_FOREACH_SAFE(res, &g->reslist, next, tmp) {
>>> -        virtio_gpu_resource_destroy(g, res);
>>> +    /*
>>> +     * If guest is suspending, we shouldn't destroy resources,
>>> +     * otherwise, the display can't come back to the time when
>>> +     * it was suspended after guest resumed.
>>> +     */
>>> +    if (!g->freezing) {
>>> +        QTAILQ_FOREACH_SAFE(res, &g->reslist, next, tmp) {
>>> +            virtio_gpu_resource_destroy(g, res);
>>> +        }
>>>        }
>>>          while (!QTAILQ_EMPTY(&g->cmdq)) {
>>> diff --git a/include/hw/virtio/virtio-gpu.h b/include/hw/virtio/virtio-gpu.h
>>> index 2e28507efe..c21c2990fb 100644
>>> --- a/include/hw/virtio/virtio-gpu.h
>>> +++ b/include/hw/virtio/virtio-gpu.h
>>> @@ -173,6 +173,7 @@ struct VirtIOGPU {
>>>          uint64_t hostmem;
>>>    +    bool freezing;
>>>        bool processing_cmdq;
>>>        QEMUTimer *fence_poll;
>>>        QEMUTimer *print_stats;
>>> @@ -284,5 +285,7 @@ void virtio_gpu_virgl_reset_scanout(VirtIOGPU *g);
>>>    void virtio_gpu_virgl_reset(VirtIOGPU *g);
>>>    int virtio_gpu_virgl_init(VirtIOGPU *g);
>>>    int virtio_gpu_virgl_get_num_capsets(VirtIOGPU *g);
>>> +void virtio_gpu_cmd_status_freezing(VirtIOGPU *g,
>>> +                         struct virtio_gpu_ctrl_command *cmd);
>>>      #endif
>>> diff --git a/include/standard-headers/linux/virtio_gpu.h b/include/standard-headers/linux/virtio_gpu.h
>>> index 2da48d3d4c..aefffbd751 100644
>>> --- a/include/standard-headers/linux/virtio_gpu.h
>>> +++ b/include/standard-headers/linux/virtio_gpu.h
>>> @@ -116,6 +116,9 @@ enum virtio_gpu_ctrl_type {
>>>        VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID,
>>>        VIRTIO_GPU_RESP_ERR_INVALID_CONTEXT_ID,
>>>        VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER,
>>> +
>>> +    /* status */
>>> +    VIRTIO_GPU_CMD_STATUS_FREEZING = 0x1300,
>>>    };
>>>      enum virtio_gpu_shm_id {
>>> @@ -453,4 +456,10 @@ struct virtio_gpu_resource_unmap_blob {
>>>        uint32_t padding;
>>>    };
>>>    +/* VIRTIO_GPU_CMD_STATUS_FREEZING */
>>> +struct virtio_gpu_status_freezing {
>>> +    struct virtio_gpu_ctrl_hdr hdr;
>>> +    __u32 freezing;
>>> +};
>>> +
>>>    #endif


  reply	other threads:[~2023-06-30 16:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-08  2:56 [QEMU PATCH 0/1] Jiqian Chen
2023-06-08  2:56 ` [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend Jiqian Chen
2023-06-08 16:41   ` Robert Beckett
2023-06-09  3:43     ` Chen, Jiqian
2023-06-15  7:23     ` Chen, Jiqian
2023-06-12 12:42   ` Marc-André Lureau
2023-06-15  7:14     ` Chen, Jiqian
2023-06-19 12:51     ` Gerd Hoffmann
2023-06-20  9:11       ` Chen, Jiqian
2023-06-20  9:41         ` Gerd Hoffmann
2023-06-20 12:26           ` Robert Beckett
2023-06-20 17:57             ` Kim, Dongwon
2023-06-21  8:39             ` Gerd Hoffmann
2023-06-21 11:14               ` Robert Beckett
2023-06-21 11:52                 ` Gerd Hoffmann
2023-06-29 16:48                 ` Kim, Dongwon
2023-06-29 16:53   ` Kim, Dongwon
2023-06-30  7:14     ` Chen, Jiqian
2023-06-30 16:18       ` Kim, Dongwon [this message]
2023-06-08  7:06 ` [QEMU PATCH 0/1] Chen, Jiqian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5edb57f9-4c11-270b-a9de-c176ec1875fd@intel.com \
    --to=dongwon.kim@intel.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).