From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjZOs-0000J6-75 for qemu-devel@nongnu.org; Wed, 20 Jul 2011 12:13:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjZOq-0006ik-H8 for qemu-devel@nongnu.org; Wed, 20 Jul 2011 12:13:29 -0400 Received: from goliath.siemens.de ([192.35.17.28]:27731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjZOp-0006iA-RP for qemu-devel@nongnu.org; Wed, 20 Jul 2011 12:13:28 -0400 Message-ID: <4E26FEA3.7080708@siemens.com> Date: Wed, 20 Jul 2011 18:13:23 +0200 From: Jan Kiszka 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> <4E26FBFB.504@redhat.com> In-Reply-To: <4E26FBFB.504@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Avi Kivity Cc: "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "Michael S. Tsirkin" On 2011-07-20 18:02, Avi Kivity wrote: > 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. Mmm, will think about how to get rid of the start/stop callbacks at least from the memory client interface. > >> 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. Legacy mem and also VBE aren't registered as aliases, but as independent memory regions. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux