Re: Nested SVM and migration

[Zachary Amsden <zamsden@redhat.com>]

On 02/21/2010 02:10 AM, Joerg Roedel wrote:
> On Sat, Feb 20, 2010 at 01:26:49PM -1000, Zachary Amsden wrote:
>    
>> The infrastructure is already there to import / export and migrate MSR
>> settings.  MSRs are also 64-bit, and hold "model-specific" settings, so
>> if you don't mind thinking of the nested feature as a model-specific
>> feature of the KVM-SVM CPU, it's even somewhat well defined in terms of
>> the architecture.
>>      
> There is a lot of additional state to migrate if the vcpu is running
> nested. To be architecturally correct you need to transfer 6kb of data
> through MSRs only for the msr permission bitmap. The rest comes down to
> the nested intercept masks and some small bits like the global interrupt
> flag and the nested vmcb address. It is doable but I still think its
> complicated to get this right. The simplest approach would be to
> disallow migration when the vcpu is running in guest mode.
>    

How is this a lot?  The guest may have multiple gigabytes of memory and 
potentially terabytes of storage.  An additional 4-8k of control state 
is not a lot.

>    
>> Mostly the problem is figuring out what chunk of MSR space to use.
>>      
> And hoping that this MSR space is not used by real hardware in the
> future ;-)
>    

There are places in MSR space that can easily be set aside for this, in 
fact, I think already are being used by Hyper-V.

And further, even if it is used by real hardware, how does it matter?  
These MSRs are to be used by control software to import / export data to 
the virtual CPU.  When being accessed by hardware virtualization, they 
can be re-aliased to any meaning at all, so there is no collision.

Zach