From: Jan Kiszka Date: Wed, 29 Apr 2009 15:42:36 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F8756C.6080503@siemens.com> List-Id: References: <49F08BD0.6000706@redhat.com> In-Reply-To: <49F08BD0.6000706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ia64@vger.kernel.org Avi Kivity wrote: > Jan Kiszka wrote: >>> If migration disables dirty memory logging, it must keep the vga logging >>> enabled, and vice versa. >>> >> >> So we need some notifier callbacks on slot changes so that all users can >> re-enable dirty logging after the update as required. > > Simpler to do reference counting. When a user enables logging for a > memory range, the refcount for all slots containing that range gets > bumped. When a user enables logging for all of memory, a global > refcount is bumped. For a given slot, dirty logging is enabled if > either the slot logging refcount or the global logging refcount is nonzero. OK, but then we just need to check for that global flag after registering/modifying slots and enable logging unconditionally. That's indeed a simple add-on. > > That's sort of what's implemented in qemu-kvm.git. In qemu.git vga > logging does not get disabled, which is really broken. It prevents > optimizations like disabling logging when the screen is not displayed to > a human. Is there a channel that tells vga "nothing will be displayed"? I may have missed it while removing all those disable-logging-as-it-may- confuse-slot-management hooks. > >> Where/how does the >> migration code disable dirty logging? >> > > Should be phase 3 of ram_save_live(). But only in qemu-kvm. What is the plan about pushing it upstream? Then we could discuss how to extend the exiting support best. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux