Hi On Wed, Jun 12, 2024 at 5:29 AM Kim, Dongwon <dongwon....@intel.com> wrote:
> Hi, > > From: Marc-André Lureau <marcandre.lur...@gmail.com> > Sent: Wednesday, June 5, 2024 12:56 AM > To: Kim, Dongwon <dongwon....@intel.com> > Cc: qemu-devel@nongnu.org; Peter Xu <pet...@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....@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....@intel.com > > <mailto:mailto:dongwon....@intel.com>> wrote: > > > > From: Dongwon <mailto:dongwon....@intel.com <mailto:mailto: > dongwon....@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? thanks -- Marc-André Lureau
