From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcEmB-0001p5-VU for qemu-devel@nongnu.org; Thu, 30 Jun 2011 06:47:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcEmA-0001qq-Pr for qemu-devel@nongnu.org; Thu, 30 Jun 2011 06:47:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcEmA-0001qm-El for qemu-devel@nongnu.org; Thu, 30 Jun 2011 06:47:14 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5UAlDhi021629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Jun 2011 06:47:13 -0400 Message-ID: <4E0C5423.2060208@redhat.com> Date: Thu, 30 Jun 2011 12:46:59 +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> <4E0AE9D7.6090706@redhat.com> <20110629092133.GL30873@bow.redhat.com> <4E0AFD7C.2050209@redhat.com> <20110629113812.GS30873@bow.redhat.com> <4E0C4F52.90405@redhat.com> In-Reply-To: <4E0C4F52.90405@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: Yonit Halperin Cc: Alon Levy , qemu-devel@nongnu.org Hi, >> Right - the whole ring assumes that the same side removes. of course we >> can add an IO for that (two - FREEZE and UNFREEZE). But I think this is >> the wrong approach. Instead, rendering all the commands, and dropping the >> wait for the client. Right now if we flush we do actually wait for the >> client, >> but I plan to remove this later. (we do this right now for update_area as >> well and that's much higher frequency). > To conclude, we still need to flush the command ring before stop. We > don't want to change migration. So we still need to change spice server > api. Gerd? Yes, looks like there is no way around that to flush the command rings. When we have to change the spice-server api anyway, then we should support async I/O at libspice-server API level I think. Drop the qxl async thread, have a way to submit async requests to the worker, let libspice call us back on completion. comments? cheers, Gerd