From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45070) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbqy0-0007eI-U3 for qemu-devel@nongnu.org; Wed, 29 Jun 2011 05:21:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qbqxy-000649-PB for qemu-devel@nongnu.org; Wed, 29 Jun 2011 05:21:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbqxx-00063o-PW for qemu-devel@nongnu.org; Wed, 29 Jun 2011 05:21:50 -0400 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5T9Lk15002396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 Jun 2011 05:21:47 -0400 Date: Wed, 29 Jun 2011 11:21:33 +0200 From: Alon Levy Message-ID: <20110629092133.GL30873@bow.redhat.com> References: <20110622095754.GG14599@bow.redhat.com> <730034918.33031.1309107546747.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <20110626174715.GJ2731@bow.redhat.com> <4E08231D.30506@redhat.com> <20110627081635.GN2731@bow.redhat.com> <4E083E8B.7010302@redhat.com> <20110627092036.GR2731@bow.redhat.com> <4E0AE9D7.6090706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0AE9D7.6090706@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/2] qxl: add QXL_IO_UPDATE_MEM for guest S3&S4 support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: yhalperi , qemu-devel@nongnu.org On Wed, Jun 29, 2011 at 11:01:11AM +0200, Gerd Hoffmann wrote: > Hi, > > >>I think it will receive them after migration, since the command ring > >>was stored. > >Our confusion here is because you think there is still seemless migration. Unfortunately > >it doesn't work right now, unless you plan to fix it the only form of migration right > >now is switch-host, and for that those commands will be lost, the new connection will receive > >images for each surface. If you treat the client as seemless you are completely right. > > The spice server needs this too so it can render the surfaces > correctly before sending the surface images to the client (or send > the old surfaces and the commands on top of that). > > That is one difference between qemu migration and S3 state: For qemu > migration it is no problem to have unprocessed commands in the > rings, they will simply be processed once the spice server state is > restored. When the guest driver restores the state when it comes > back from S3 it needs the command rings to do so, thats why they > must be flushed before entering S3 ... You mean it needs the command rings to be empty before, since they are lost during the reset, right? > > cheers, > Gerd >