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
--
To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
