Re: [PATCH] ui/gtk: Wait until the current guest frame is rendered before switching to RUN_STATE_SAVE_VM

["Kim, Dongwon" <dongwon.kim@intel.com>]

On 6/11/2024 10:44 PM, Marc-André Lureau wrote:
> Hi
> 
> On Wed, Jun 12, 2024 at 5:29 AM Kim, Dongwon <dongwon.kim@intel.com 
> <mailto:dongwon.kim@intel.com>> wrote:
> 
>     Hi,
> 
>     From: Marc-André Lureau <marcandre.lureau@gmail.com
>     <mailto:marcandre.lureau@gmail.com>>
>     Sent: Wednesday, June 5, 2024 12:56 AM
>     To: Kim, Dongwon <dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>
>     Cc: qemu-devel@nongnu.org <mailto:qemu-devel@nongnu.org>; Peter Xu
>     <peterx@redhat.com <mailto:peterx@redhat.com>>
>     Subject: Re: [PATCH] ui/gtk: Wait until the current guest frame is
>     rendered before switching to RUN_STATE_SAVE_VM
> 
>     Hi
> 
>     On Tue, Jun 4, 2024 at 9:49 PM Kim, Dongwon
>     <mailto:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>> wrote:
>     On 6/4/2024 4:12 AM, Marc-André Lureau wrote:
>      > Hi
>      >
>      > On Thu, May 30, 2024 at 2:44 AM <mailto:dongwon.kim@intel.com
>     <mailto:dongwon.kim@intel.com>
>      > <mailto:mailto <mailto:mailto>:dongwon.kim@intel.com
>     <mailto:dongwon.kim@intel.com>>> wrote:
>      >
>      >     From: Dongwon <mailto:dongwon.kim@intel.com
>     <mailto:dongwon.kim@intel.com> <mailto:mailto
>     <mailto:mailto>:dongwon.kim@intel.com <mailto:dongwon.kim@intel.com>>>
>      >
>      >     Make sure rendering of the current frame is finished before
>     switching
>      >     the run state to RUN_STATE_SAVE_VM by waiting for egl-sync
>     object to be
>      >     signaled.
>      >
>      >
>      > Can you expand on what this solves?
> 
>     In current scheme, guest waits for the fence to be signaled for each
>     frame it submits before moving to the next frame. If the guest’s state
>     is saved while it is still waiting for the fence, The guest will
>     continue to  wait for the fence that was signaled while ago when it is
>     restored to the point. One way to prevent it is to get it finish the
>     current frame before changing the state.
> 
>     After the UI sets a fence, hw_ops->gl_block(true) gets called, which
>     will block virtio-gpu/virgl from processing commands (until the
>     fence is signaled and gl_block/false called again).
> 
>     But this "blocking" state is not saved. So how does this affect
>     save/restore? Please give more details, thanks
> 
>     Yeah sure. "Blocking" state is not saved but guest's state is saved
>     while it was still waiting for the response for its last
>     resource-flush virtio msg. This virtio response, by the way is set
>     to be sent to the guest when the pipeline is unblocked (and when the
>     fence is signaled.). Once the guest's state is saved, current
>     instance of guest will be continued and receives the response as
>     usual. The problem is happening when we restore the saved guest's
>     state again because what guest does will be waiting for the response
>     that was sent a while ago to the original instance.
> 
> 
> Where is the pending response saved? Can you detail how you test this?
> 

There is no pending response for the guest's restored point, which is a 
problem. The response is sent out after saving is done.

Normal cycle :

resource-flush (scanout flush) -> gl block -> render -> gl unblock 
(after fence is signaled) -> pending response sent out to the guest -> 
guest (virtio-gpu drv) processes the next scanout frame -> (next cycle) 
resource-flush -> gl block ......

When vm state is saved in the middle :

resource-flush (scanout-flush) -> gl block -> saving vm-state -> render 
-> gl unblock -> pending response (resp #1) sent out to the guest -> 
guest (virtio-gpu drv) processes the next scanout frame -> (next cycle) 
resource-flush -> gl block ......

Now, we restore the vm-state we saved

vm-state is restored -> guest (virtio-gpu drv) can't move on as this 
state is still waiting for the response (resp #1)

So we need to make sure vm-state is saved after the cycle is completed.

This situation would be only happening if you use blob=true with 
virtio-gpu drv as KMS on the linux guest. Do you have any similar setup?

> thanks
> 
> -- 
> Marc-André Lureau