Zachary Amsden 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. > > Unless you also migrate the hypercall page itself and impose migration > restrictions on compatible hypercall pages.
Compatible hypercall pages == identical hypercall pages. This also comes into play with save/restore. If you save a guest, then upgrade the hypervisor, if the new hypervisor uses a different hypercall page (perhaps b/c an internal interface has changed), you run into the same problem. > Although I favor the guarantee that execution within the hypercall > page is finished - it is important for protecting against > non-reentrancy as well. Think about interrupts during batching / > queueing operations. I think this is pretty straight forward to do without guest cooperation. You merely have to let the guest run a little longer until vcpu->eip is not in the hypercall page. This just becomes part of the criteria for convergence in migration. The guest could get nasty and loop hard on calling into the hypercall page or, worse yet, rewrite portions of the hypercall page so that execution stayed indefinitely there. That could be mitigated with heuristics but that's probably not all that important. Of course, you also have to guarantee that the hypercall page doesn't maintain any state (at least, within the page itself). That's definitely a limiting factor. Regards, Anthony Liguori > Zach > ------------------------------------------------------------------------- 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
