From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZKCB-0000HF-RT for qemu-devel@nongnu.org; Wed, 22 Jun 2011 05:58:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QZKCA-0005R7-V2 for qemu-devel@nongnu.org; Wed, 22 Jun 2011 05:58:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QZKCA-0005Qw-O0 for qemu-devel@nongnu.org; Wed, 22 Jun 2011 05:58:02 -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 p5M9w0Ku032186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Jun 2011 05:58:00 -0400 Date: Wed, 22 Jun 2011 11:57:54 +0200 From: Alon Levy Message-ID: <20110622095754.GG14599@bow.redhat.com> References: <1308568312-5463-1-git-send-email-alevy@redhat.com> <1308568312-5463-3-git-send-email-alevy@redhat.com> <4DFF3970.8000804@redhat.com> <20110620125821.GB28412@bow.redhat.com> <4DFF543F.9070205@redhat.com> <20110620151107.GE28412@bow.redhat.com> <4DFF6C48.2020401@redhat.com> <20110620163230.GG28412@bow.redhat.com> <4E01B22F.3020702@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E01B22F.3020702@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@redhat.com, qemu-devel@nongnu.org On Wed, Jun 22, 2011 at 11:13:19AM +0200, Gerd Hoffmann wrote: > Hi, > > >>worker call. We can add a I/O command to ask qxl to push the > >>release queue head to the release ring. > > > >So you suggest to replace QXL_IO_UPDATE_MEM with what, two io commands instead > >of using the val parameter? > > I'd like to (a) avoid updating the libspice-server API if possible > and (b) have one I/O command for each logical step. So going into > S3 could look like this: > > (0) stop putting new commands into the rings > (1) QXL_IO_NOTIFY_CMD > (2) QXL_IO_NOTIFY_CURSOR > qxl calls notify(), to make the worker thread empty the command > rings before it processes the next dispatcher request. > (3) QXl_IO_FLUSH_SURFACES (to be implemented) > qxl calls stop()+start(), spice-server renders all surfaces, > thereby flushing state to device memory. > (4) QXL_IO_DESTROY_ALL_SURFACES > zap surfaces > (5) QXL_IO_FLUSH_RELEASE (to be implemented) > push release queue head into the release ring, so the guest > will see it and can release everything. > > (1)+(2)+(4) exist already. > (3)+(5) can be done without libspice-server changes. > > Looks workable? yeah. Yonit? > > cheers, > Gerd > >