From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjXtV-0000LQ-MK for qemu-devel@nongnu.org; Wed, 20 Jul 2011 10:37:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjXtT-0004JW-Ra for qemu-devel@nongnu.org; Wed, 20 Jul 2011 10:37:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjXtS-0004IP-Px for qemu-devel@nongnu.org; Wed, 20 Jul 2011 10:36:59 -0400 Date: Wed, 20 Jul 2011 17:37:20 +0300 From: "Michael S. Tsirkin" Message-ID: <20110720143720.GC6787@redhat.com> References: <1310901265-32051-1-git-send-email-avi@redhat.com> <20110719135601.GA7194@redhat.com> <4E25B85C.1030809@siemens.com> <4E25BB7A.7030105@redhat.com> <4E25BF26.6080900@siemens.com> <4E268E20.5050807@redhat.com> <4E26BF77.7070705@siemens.com> <4E26C290.8010604@redhat.com> <4E26DECC.9000700@siemens.com> <4E26E716.2090109@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E26E716.2090109@redhat.com> Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Jan Kiszka , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" On Wed, Jul 20, 2011 at 05:32:54PM +0300, Avi Kivity wrote: > On 07/20/2011 04:57 PM, Jan Kiszka wrote: > >Something around dirty logging is still seriously borken: when I boot > >with standard or cirrus vga, the screen is not properly updated in > >logged modes. > > > > I don't see this here, will retest. > > >I bet the reason is lacking semantics of > >cpu_register_physical_memory_log(..., true), ie. the chance to register > >a memory region with logging enabled. We need to explicitly enable it > >now via memory_region_set_log, right? Is there any ordering issue to > >expect, ie. when can I first call memory_region_set_log (as it issues > >the start/stop client callbacks)? > > There should be no ordering issue at all. > > If you do a memory_region_set_log() immediately after > memory_region_init_ram(), then as soon as the framebuffer is added > to the memory hierarchy, it will have logging enabled (or any > aliases of the framebuffer). Still, I think we should specify logging on/off when region is created, and avoid APIs that tweak dirty logging. I don't think there's actual need for device to enable/disable logging. What devices seem to need, instead, is enable/disable a region through a back channel. > -- > error compiling committee.c: too many arguments to function