From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Date: Thu, 30 Apr 2009 15:32:33 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F9C491.80205@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: >> 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. No one said this. > >> >>> 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. The existing support lacked features upstream already had and instead required additional hacks to make qemu-kvm work. > > 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. I doubt this applies here. > >> So, what bits are missing to make KVM migration work in upstream? >> > > I don't know of anything beyond dirty logging. > OK, then I will pick this up and have a look at something comparable to cpu_physical_memory_set_dirty_tracking() for upstream. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Date: Thu, 30 Apr 2009 15:32:33 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F9C491.80205@siemens.com> List-Id: References: <49F08BD0.6000706@redhat.com> <49F81496.8030407@siemens.com> <49F82F24.8040506@redhat.com> <49F83227.9000502@siemens.com> <49F83630.6020402@redhat.com> <49F83A8A.8040909@siemens.com> <49F866C3.8090904@redhat.com> <49F8756C.6080503@siemens.com> <49F96B6F.6050005@redhat.com> <49F96F5E.6060404@siemens.com> <49F98365.3080907@redhat.com> In-Reply-To: <49F98365.3080907-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Avi Kivity Cc: KVM list , Anthony Liguori , Hollis Blanchard , "Zhang, Xiantao" , kvm-ppc , "kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Carsten Otte Avi Kivity wrote: > 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. No one said this. > >> >>> 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. The existing support lacked features upstream already had and instead required additional hacks to make qemu-kvm work. > > 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. I doubt this applies here. > >> So, what bits are missing to make KVM migration work in upstream? >> > > I don't know of anything beyond dirty logging. > OK, then I will pick this up and have a look at something comparable to cpu_physical_memory_set_dirty_tracking() for upstream. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: qemu-kvm.git now live Date: Thu, 30 Apr 2009 17:32:33 +0200 Message-ID: <49F9C491.80205@siemens.com> References: <49F08BD0.6000706@redhat.com> <49F81496.8030407@siemens.com> <49F82F24.8040506@redhat.com> <49F83227.9000502@siemens.com> <49F83630.6020402@redhat.com> <49F83A8A.8040909@siemens.com> <49F866C3.8090904@redhat.com> <49F8756C.6080503@siemens.com> <49F96B6F.6050005@redhat.com> <49F96F5E.6060404@siemens.com> <49F98365.3080907@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: KVM list , Anthony Liguori , Hollis Blanchard , "Zhang, Xiantao" , kvm-ppc , "kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Carsten Otte To: Avi Kivity Return-path: In-Reply-To: <49F98365.3080907-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: kvm.vger.kernel.org Avi Kivity wrote: > 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. No one said this. > >> >>> 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. The existing support lacked features upstream already had and instead required additional hacks to make qemu-kvm work. > > 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. I doubt this applies here. > >> So, what bits are missing to make KVM migration work in upstream? >> > > I don't know of anything beyond dirty logging. > OK, then I will pick this up and have a look at something comparable to cpu_physical_memory_set_dirty_tracking() for upstream. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html