From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbqe5-0005Na-FP for qemu-devel@nongnu.org; Wed, 29 Jun 2011 05:01:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qbqe3-0002ux-Tg for qemu-devel@nongnu.org; Wed, 29 Jun 2011 05:01:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbqe3-0002ut-FB for qemu-devel@nongnu.org; Wed, 29 Jun 2011 05:01:15 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5T91EEk007337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 Jun 2011 05:01:14 -0400 Message-ID: <4E0AE9D7.6090706@redhat.com> Date: Wed, 29 Jun 2011 11:01:11 +0200 From: Gerd Hoffmann MIME-Version: 1.0 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> In-Reply-To: <20110627092036.GR2731@bow.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: yhalperi , qemu-devel@nongnu.org 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 ... cheers, Gerd