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 > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
