From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjZDw-0005E1-OY for qemu-devel@nongnu.org; Wed, 20 Jul 2011 12:02:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjZDu-0004mp-8y for qemu-devel@nongnu.org; Wed, 20 Jul 2011 12:02:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjZDt-0004mS-Aa for qemu-devel@nongnu.org; Wed, 20 Jul 2011 12:02:09 -0400 Message-ID: <4E26FBFB.504@redhat.com> Date: Wed, 20 Jul 2011 19:02:03 +0300 From: Avi Kivity MIME-Version: 1.0 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> <20110720143720.GC6787@redhat.com> <4E26EC22.1030309@redhat.com> <4E26FB34.4080507@siemens.com> In-Reply-To: <4E26FB34.4080507@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" On 07/20/2011 06:58 PM, Jan Kiszka wrote: > On 2011-07-20 16:54, Avi Kivity wrote: > > On 07/20/2011 05:37 PM, Michael S. Tsirkin wrote: > >>> > >>> 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. > > > > It's the same thing. > > > > memory_region_init*(); > > // we have a disconnected memory region > > memory_region_set_log(); > > // still disconnected, now logged > > > > I don't want memory_region_init() with 231 parameters. > > That's OK. The question is if memory_region_set_log should work on both > invisible AND visible regions. The former makes it a bit-flip service, > the latter requires a larger machinery. > It works on both visible and invisible regions. Again, the entire point of this API is that visibility of a region to the cpu is not dependent on the device itself, but also on buses in the hierarchy. If a device wants a region to be logged (or coalesced) it indicates this to the API, and the core does the rest. > BTW, what's broken is legacy VGA mem dirty logging. Was simply dropped > during the conversion, and now I'm missing some links between vga core > and its users to reestablish it generically. You mean logging of 0xa0000-0xc0000? That's probably a bug in the core. Once you enable logging of the framebuffer, any aliases should inherit it. -- error compiling committee.c: too many arguments to function