Re: Nested SVM and migration

[Avi Kivity <avi@redhat.com>]

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