Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration
gets really difficult if you have anything but a trivial hypercall
page since the hypercall page will change after migration.
If you cannot guarantee the guest isn't executing code within the
hypercall page (or in your case, doing something with paravirt_ops),
then you cannot safely migrate.
Hm, you need to quiesce the kernel in some way when you do a migrate,
so making sure it isn't in a hypercall would be just part of that. In
general you'd make sure all but one CPU is parked somewhere, and the
remaining CPU is doing the suspend, right?
The real trick is doing it without the guest being involved at all.
Right now, it won't be a problem in KVM since the hypercall page only
differs by a single instruction across platforms. In the future, we'll
have to be smarter and wait for all VCPUs to leave the hypercall page.
The tricky part for Xen in all this is how to make sure all mfn
references are visible to the hypervisor/toolstack so they can be
remapped; hypercall page contents are not a concern by comparison.
I don't know HVM save/resume all that well but I think it's a similar
model where the guest isn't involved. They may have a similar issue
when using PV drivers.
Regards,
Anthony Liguori
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
