From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53219) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYuSK-0006LA-BH for qemu-devel@nongnu.org; Tue, 21 Jun 2011 02:29:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYuSI-0006nN-Ro for qemu-devel@nongnu.org; Tue, 21 Jun 2011 02:29:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13447) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYuSI-0006nJ-Df for qemu-devel@nongnu.org; Tue, 21 Jun 2011 02:28:58 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5L6SuSS006403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 21 Jun 2011 02:28:56 -0400 Message-ID: <4E003A50.8060009@redhat.com> Date: Tue, 21 Jun 2011 09:29:36 +0300 From: Yonit Halperin MIME-Version: 1.0 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> In-Reply-To: <20110620163230.GG28412@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: Gerd Hoffmann , qemu-devel@nongnu.org, Alon Levy On 06/20/2011 07:32 PM, Alon Levy wrote: > On Mon, Jun 20, 2011 at 05:50:32PM +0200, Gerd Hoffmann wrote: >> On 06/20/11 17:11, Alon Levy wrote: >>> On Mon, Jun 20, 2011 at 04:07:59PM +0200, Gerd Hoffmann wrote: >>>>>> What is the difference to one worker->stop() + worker->start() cycle? >>>>>> >>>>> >>>>> ok, stop+start won't disconnect any clients either. But does stop render all waiting commands? >>>>> I'll have to look, I don't know if it does. >>>> >>>> It does. This is what qemu uses to flush all spice server state to >>>> device memory on migration. I don't see that STOP flushes the command rings. We must read and empty the command rings before going to S3. >>>> >>>> What is the reason for deleting all surfaces? >>> >>> Making sure all references are dropped to pci memory in devram. >> >> Ah, because the spice server keeps a reference to the create command >> until the surface is destroyed, right? > > Actually right, so my correction stands corrected. > >> >> There is is QXL_IO_DESTROY_ALL_SURFACES + worker->destroy_surfaces() ... >> > > Regarding QXL_IO_DESTROY_ALL_SURFACES, it destroys the primary surface too, > which is a little special, that's another difference - update_mem destroys > everything except the primary. I know I tried to destroy the primary but it > didn't work right, don't recall why right now, so I guess I'll have to retry. > I guess it is because DrvAssertMode(disable) destroyed the primary surface in a separate call. Don't think we need to separate the calls any more (we probably needed it when we thought S3 and resolution changes will have different paths). >> The QXL_IO_UPDATE_MEM command does too much special stuff IMHO. >> I also think we don't need to extend the libspice-server API. >> >> We can add a I/O command which renders everything to device memory >> via stop+start. We can zap all surfaces with the existing command + > Yes, start+stop work nicely, didn't realize (saw it before, assumed > it wouldn't be good enough), just need to destroy the surfaces too. > >> 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? > QXL_IO_UPDATE_MEM > QXL_IO_FLUSH_RELEASE > ? > >> >> Comments? >> >> cheers, >> Gerd >>