From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Merging KVM live migration upstream Date: Fri, 01 May 2009 14:02:36 +0300 Message-ID: <49FAD6CC.9040708@redhat.com> References: <49FABCF2.70909@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Uri Lublin , Anthony Liguori , kvm-devel To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36312 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754814AbZEALCl (ORCPT ); Fri, 1 May 2009 07:02:41 -0400 In-Reply-To: <49FABCF2.70909@web.de> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > Avi or Uri, > > could you explain the first and third hunk? Why are they needed in > qemu-kvm, and will we also need something comparable upstream? They do > not look very beautiful. > > These date from the bad old days where we relied on phys_ram_base. I think this is obsolete. Since we reserve these memory addresses, it won't do any harm, but we can certainly remove them. > The second hunk, I guess, should become a kvm hook to > cpu_physical_memory_get_dirty - or is this too costly for other users of > this inline function? > Note the dependency on current_addr: this is meant to happen every time we cycle through all memory, so it doesn't fit in cpu_physical_memory_get_dirty(). > And does anyone knows further migration-related hunks that are missing > upstream (except for the KVM hook in > cpu_physical_memory_set_dirty_tracking)? > > We need to make sure vga plays well with this, like we discussed. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.