Re: [PATCH 0/5] KVM paravirt_ops implementation

Anthony Liguori
2007-06-20T22:08:15Z

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