Re: [PATCH 0/5] KVM paravirt_ops implementation

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/