From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47763) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcFcv-0001gC-BH for qemu-devel@nongnu.org; Thu, 30 Jun 2011 07:41:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcFct-0002ZU-Ho for qemu-devel@nongnu.org; Thu, 30 Jun 2011 07:41:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4053) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcFct-0002ZG-1W for qemu-devel@nongnu.org; Thu, 30 Jun 2011 07:41:43 -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 p5UBfepw020310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Jun 2011 07:41:40 -0400 Date: Thu, 30 Jun 2011 13:41:34 +0200 From: Alon Levy Message-ID: <20110630114134.GH26431@bow.redhat.com> References: <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> <4E0C5423.2060208@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0C5423.2060208@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: Yonit Halperin , qemu-devel@nongnu.org On Thu, Jun 30, 2011 at 12:46:59PM +0200, Gerd Hoffmann wrote: > 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? My thoughts exactly. Any reason to support the old non async messages if we do this? i.e. do we add _ASYNC versions or just change the meaning of the existing ones? as long as we change the major version of the server (it will be 0.10) I think it isn't problematic, right? The only difference with this approach is that we will have to do the reads from the io thread of qemu, which means a single thread reading for multiple qxl devices, but since it will just be doing very minimal work I don't think it should be a problem (it will just be setting the irq). > > cheers, > Gerd