From patchwork Mon Jun 20 20:53:47 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alon Levy X-Patchwork-Id: 101208 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [140.186.70.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E9515B6F80 for ; Tue, 21 Jun 2011 07:03:02 +1000 (EST) Received: from localhost ([::1]:40225 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYlcX-00005i-IU for incoming@patchwork.ozlabs.org; Mon, 20 Jun 2011 17:02:57 -0400 Received: from eggs.gnu.org ([140.186.70.92]:34619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYlTu-00078m-9A for qemu-devel@nongnu.org; Mon, 20 Jun 2011 16:54:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYlTs-0004D3-TJ for qemu-devel@nongnu.org; Mon, 20 Jun 2011 16:54:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYlTs-0004Cz-D2 for qemu-devel@nongnu.org; Mon, 20 Jun 2011 16:54:00 -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 p5KKrwHS003335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Jun 2011 16:53:58 -0400 Received: from bow.redhat.com (vpn-9-93.rdu.redhat.com [10.11.9.93]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p5KKrrDF016864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Jun 2011 16:53:56 -0400 Date: Mon, 20 Jun 2011 22:53:47 +0200 From: Alon Levy To: Gerd Hoffmann , qemu-devel@nongnu.org, yhalperi@redhat.com Message-ID: <20110620205250.GH28412@bow.redhat.com> Mail-Followup-To: Gerd Hoffmann , qemu-devel@nongnu.org, yhalperi@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20110620163230.GG28412@bow.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH 2/2] qxl: add QXL_IO_UPDATE_MEM for guest S3&S4 support X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Mon, Jun 20, 2011 at 06:32:30PM +0200, 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. > > >> > > >>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. > > > 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. > ok, it all works nicely except with the current driver patches I get a double destroy for the primary surface. Removing it with the following patch makes everything (resolution change/suspend/hibernate) work. I would really suggest we remove that PANIC_ON, besides of course fixing the driver patches (I'll do a v2 for the affected patche, the last series of qxl, I didn't cc you since I didn't assume you'd want to review, but you probably saw it). Something like: > > 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 > > > diff --git a/server/red_worker.c b/server/red_worker.c index f0a8dfc..3b53a3f 100644 --- a/server/red_worker.c +++ b/server/red_worker.c @@ -9684,7 +9684,11 @@ static inline void handle_dev_destroy_primary_surface(RedWorker *worker) receive_data(worker->channel, &surface_id, sizeof(uint32_t)); PANIC_ON(surface_id != 0); - PANIC_ON(!worker->surfaces[surface_id].context.canvas); + + if (!worker->surfaces[surface_id].context.canvas) { + red_printf("warning: double destroy of primary surface\n"); + goto end; + } if (worker->cursor) { red_release_cursor(worker, worker->cursor); @@ -9711,6 +9715,7 @@ static inline void handle_dev_destroy_primary_surface(RedWorker *worker) worker->cursor_position.x = worker->cursor_position.y = 0; worker->cursor_trail_length = worker->cursor_trail_frequency = 0; +end: message = RED_WORKER_MESSAGE_READY; write_message(worker->channel, &message); }