From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Date: Thu, 30 Apr 2009 09:29:02 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F96F5E.6060404@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: >>>> 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)? > 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. So, what bits are missing to make KVM migration work in 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 09:29:02 +0000 Subject: Re: qemu-kvm.git now live Message-Id: <49F96F5E.6060404@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> In-Reply-To: <49F96B6F.6050005-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: >>>> 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)? > 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. So, what bits are missing to make KVM migration work in 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 11:29:02 +0200 Message-ID: <49F96F5E.6060404@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> 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: <49F96B6F.6050005-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: kvm.vger.kernel.org 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)? > 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. So, what bits are missing to make KVM migration work in 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