Re: Nested SVM and migration

Zachary Amsden
2010-02-22T16:40:03Z

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