From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47100 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNlzC-000552-Bx for qemu-devel@nongnu.org; Wed, 01 Dec 2010 07:40:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNlys-0001Dt-RQ for qemu-devel@nongnu.org; Wed, 01 Dec 2010 07:40:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:23976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNlys-0001DT-Kd for qemu-devel@nongnu.org; Wed, 01 Dec 2010 07:40:18 -0500 Message-ID: <4CF6422C.3030308@redhat.com> Date: Wed, 01 Dec 2010 14:40:12 +0200 From: Avi Kivity MIME-Version: 1.0 References: <9b23b9b4cee242591bdb356c838a9cfb9af033c1.1290552026.git.quintela@redhat.com> <4CF45D67.5010906@codemonkey.ws> <4CF4A478.8080209@redhat.com> <4CF5008F.2090306@codemonkey.ws> <4CF5030B.40703@redhat.com> <4CF50783.90402@codemonkey.ws> <4CF509C1.9@redhat.com> <4CF50F2C.7090503@codemonkey.ws> In-Reply-To: <4CF50F2C.7090503@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 09/10] Exit loop if we have been there too long List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , Juan Quintela , qemu-devel@nongnu.org, kvm-devel , Juan Quintela On 11/30/2010 04:50 PM, Anthony Liguori wrote: >> That's what the patch set I was alluding to did. Or maybe I imagined >> the whole thing. > > > No, it just split the main bitmap into three bitmaps. I'm suggesting > that we have the dirty interface have two implementations, one that > refers to the 8-bit bitmap when TCG in use and another one that uses > the KVM representation. > > TCG really needs multiple dirty bits but KVM doesn't. A shared > implementation really can't be optimal. Live migration and the framebuffer can certainly share code with kvm and tcg: - tcg or kvm maintain an internal bitmap (kvm in the kernel, tcg updates a private bitmap) - a dirty log client wants to see an updated bitmap; migration on a new pass, vga on screen refresh - ask the producer (kvm or tcg) to fetch-and-clear a dirty bitmap - broadcast it ( |= ) into any active clients (migration or framebuffer) - everyone's happy The code dirty thing might need special treatment, we can have a special tcg-only bitmap for it. -- error compiling committee.c: too many arguments to function