Re: [PATCH 0/5] KVM paravirt_ops implementation

[Zachary Amsden <zach-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>]

Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>> Unless you also migrate the hypercall page itself and impose 
>> migration restrictions on compatible hypercall pages.
>
> Seems unreasonable, especially if you support migration between VT and 
> SVM machines.  The whole point of a hypercall page is to give you a 
> point of indirection in order to hide these kinds of hardware 
> differences; migrating it would defeat the purpose.

Migrating across Intel<->AMD is likely to be problematic for many other 
reasons, and in general, migrating between such different hardware (yes, 
different instruction sets even) will probably not be possible in the 
majority of cases.

If I had a gentoo install, I would probably go so far as to want to 
recompile everything after migration across CPU vendors; things like 
NMIs, MSRs, thermal controls and sleep states are also vendor dependent 
and either need to be emulated both ways, re-invented in a new way 
entirely, or just dropped.

I don't think cross-CPU vendor hot migration is particularly compelling, 
although it certainly is possible, the payoff doesn't seem worth the 
implementation cost and you will find a maze of brambly thorns blocking 
your path.

>> 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.
>
> Not quite sure that's specifically relevant to migration, but yes, its 
> important to disable interrupts while doing the setup for a batch of 
> stuff unless you want to see some surprises in your queue (and not 
> "Oh, yay, a puppy!" kind of surprises).

I would argue making the hypercall page atomic is a better solution to 
reentrancy than disable / enable, but perhaps just because it happened 
to work out very nicely for our implementation.  The point is, that also 
solves part of the migration problem.

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/