Re: Nested SVM and migration

Avi Kivity
2010-02-21T12:54:10Z

On 02/21/2010 02:41 PM, Joerg Roedel wrote:
> On Sun, Feb 21, 2010 at 02:24:02PM +0200, Avi Kivity wrote:
>
>> On 02/21/2010 02:10 PM, 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 msr permission bitmap is in guest memory, so it is already migrated.
>>
> This will work almost always but its not architecturally correct
> because the memory contents may have changed since the last vmrun
> instruction. On the other hand we already have this problem with the
> current nested msr intercept handling...
>

So, if some other cpu (or the guest itself, with appropriate
permissions) modifies the msr permission bitmap, svm will not notice
this? svm loads the bitmap during entry?

>>> The rest comes down to
>>> the nested intercept masks
>>>
>> These are in the vmcb, which is in guest memory.
>>
> Same as with the MSR permission map here.
>
>

Yes (as with the msr permission bitmap pointers).

>>> 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.
>>>
>>>
>> Agree, though I dislike the need to introduce a "force vmexit" ioctl.
>>
> Yes, this has possible issues too. If we reconstruct the nested state from
> the nested vmcb there is not much state left which needs migration. But
> we should keep in mind that this is not how real hardware works.
>

I don't think you can tell, unless the host cpu modifying the vmcb is
synchronized with the guest (or the guest modifies its own vmcb). But
this is all academic.

--
error compiling committee.c: too many arguments to function