From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40699) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjXHO-0006Kg-PM for qemu-devel@nongnu.org; Wed, 20 Jul 2011 09:57:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjXHM-0003wk-Kq for qemu-devel@nongnu.org; Wed, 20 Jul 2011 09:57:38 -0400 Received: from goliath.siemens.de ([192.35.17.28]:20251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjXHM-0003wY-2h for qemu-devel@nongnu.org; Wed, 20 Jul 2011 09:57:36 -0400 Message-ID: <4E26DECC.9000700@siemens.com> Date: Wed, 20 Jul 2011 15:57:32 +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> In-Reply-To: <4E26C290.8010604@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 13:57, Avi Kivity wrote: > On 07/20/2011 02:43 PM, Jan Kiszka wrote: >> On 2011-07-20 10:13, Avi Kivity wrote: >>> On 07/19/2011 08:30 PM, Jan Kiszka wrote: >>>>> Rebasing is already not so fun for me with 78 patches and counting. >>>>> Let's drop yours and focus of getting mine in shape, since it's a superset. >>>> >>>> The patches series are widely orthogonal except for both killing the >>>> obsolete start/stop logging logic. >>>> >>>> But I don't mind rebasing over yours - if something is finally merged at >>>> all. >>> >>> If you post patches I'll incorporate them in my patchset. They're >>> available in qemu-kvm.git branch memory-region. >> >> Is that branch up-to-date? It spits out tons of debug messages, making >> it unusable for any test. >> > > I usually redirect them away. > > I'll move the two patches on top, so it's easy to have git drop them. 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 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)? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux