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" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
