Hi
On Tue, Dec 5, 2023 at 6:40 AM Dongwon Kim <dongwon....@intel.com> wrote:
>
> If the guest state is paused before it gets a response for the current
> scanout frame submission (resource-flush), it won't start submitting
> new frames after being restored as it still waits for the old response,
> which is accepted as a scanout render done signal. So it's needed to
> unblock the current scanout render pipeline before the run state is
> changed to make sure the guest receives the response for the current
> frame submission.
>
> Cc: Marc-André Lureau <marcandre.lur...@redhat.com>
> Cc: Vivek Kasireddy <vivek.kasire...@intel.com>
> Signed-off-by: Dongwon Kim <dongwon....@intel.com>
> ---
> ui/gtk.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/ui/gtk.c b/ui/gtk.c
> index 810d7fc796..0f6237dd2f 100644
> --- a/ui/gtk.c
> +++ b/ui/gtk.c
> @@ -678,6 +678,18 @@ static const DisplayGLCtxOps egl_ctx_ops = {
> static void gd_change_runstate(void *opaque, bool running, RunState state)
> {
> GtkDisplayState *s = opaque;
> + int i;
> +
> + if (state == RUN_STATE_SAVE_VM) {
> + for (i = 0; i < s->nb_vcs; i++) {
> + VirtualConsole *vc = &s->vc[i];
> +
> + if (vc->gfx.guest_fb.dmabuf) {
&& ..dmabuf->fence_fd >= 0
> + /* force flushing current scanout blob rendering process */
> + gd_hw_gl_flushed(vc);
This defeats the purpose of the fence, maybe we should wait for it to
be signaled first. At worse, I suppose the client can have some
glitches. Although since the guest is stopped, this is unlikely.
