From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcGi0-0001gc-4G for qemu-devel@nongnu.org; Thu, 30 Jun 2011 08:51:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcGhy-0000T1-MZ for qemu-devel@nongnu.org; Thu, 30 Jun 2011 08:51:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20860) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcGhy-0000Sj-0E for qemu-devel@nongnu.org; Thu, 30 Jun 2011 08:51:02 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5UCp1nh010029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Jun 2011 08:51:01 -0400 Date: Thu, 30 Jun 2011 14:50:54 +0200 From: Alon Levy Message-ID: <20110630125054.GL26431@bow.redhat.com> References: <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> <20110630114134.GH26431@bow.redhat.com> <4E0C6844.70902@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E0C6844.70902@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 02:12:52PM +0200, Gerd Hoffmann wrote: > Hi, > > >My thoughts exactly. Any reason to support the old non async messages if we > >do this? > > Yes. Backward compatibility. So at least deprecate it to be dropped later? I don't like that the code just gets bigger and bigger. > > >The only difference with this approach is that we will have to do the reads from the > >io thread of qemu, > > Hmm? Which reads? I was thinking of a different solution - one in which the same "READY" messages are written, but read from a different place. That would not have actually required any changes to the spice-server api. But if you say you prefer to add a completion callback, that's cool. Just to answer, I was thinking of this flow for the async commands: vcpu thread -> pipe_to_red_worker : update_area_async red_worker thread -> pipe_to_io_thread : update_area_async complete but that wouldn't have worked, would it? unless we made sure to prevent tries to do async/sync while async in progress. > > I'd add a completion callback to QXLInterface. > > cheers, > Gerd > >