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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
