From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Date: Thu, 30 Apr 2009 10:54:29 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F98365.3080907@redhat.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 Jan Kiszka wrote: > Avi Kivity wrote: > >>>>> 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. >>> >>> >> Pushing things upstream is quite difficult because of the very different >> infrastructure. >> > > Isn't the midterm goal to get rid of most of these differences (namely > libkvm)? > Yes, but not by removing existing functionality. > >> It's unfortunate that upstream rewrote everything >> instead of changing things incrementally. Rewrites are almost always a >> mistake since they throw away accumulated knowledge. >> > > I disagree, at least in this particular case. Upstream already diverged > from qemu-kvm, and the latter provided no comparable alternative for > slot management and dirty logging. And I still don't see that we lost > anything that could not easily be re-integrated into upstream (ie. > global dirty logging), finally leading to a cleaner and more complete > result. > It could have been done differently, by morphing the existing support into something mergable, and merging that. In this way, we'd ensure no needed functionality is lost. As is, we're adding something simple, then discovering it's insufficient. We're throwing away information, that's not a good way to make progress. > So, what bits are missing to make KVM migration work in upstream? > I don't know of anything beyond dirty logging. -- error compiling committee.c: too many arguments to function