Re: Nested SVM and migration

[Zachary Amsden <zamsden@redhat.com>]

On 02/21/2010 05:56 AM, Joerg Roedel wrote:
> On Sun, Feb 21, 2010 at 05:07:45PM +0200, Avi Kivity wrote:
>    
>> On 02/21/2010 04:43 PM, Joerg Roedel wrote:
>>      
>>> Difficult. We could use an instruction intercept which has no side
>>> effect on guest state (invlpg for example).
>>>        
>> Especially as the guest might disable it and BUG() if npt is enabled.
>>
>>      
>>> But thats a lot more
>>> dangerous than an INTR intercept. What about PENDING_INTERRUPT? Are
>>> there hypervisors that may get confused getting this intercept without
>>> asking for it?
>>>
>>>        
>> That will likely confuse kvm, it means interrupts are not blocked so it
>> is okay to inject one, and if the guest is running with interrupts
>> disabled then the next entry will fail.
>>      
> Completly different idea:
>
> 1. Give userspace an ioctl to freeze the complete VM (all vcpus must be
>     stopped afterwards)
> 2. The freeze routine does the following:
>
> freeze_vm(...)
> {
> 	stop_all_vcpus();
> 	for_each_vcpu(vcpu)
> 		kvm_x86_ops->freeze_vcpu(vcpu);
> }
>
> The module specific freeze_vcpu function can save the nested state
> inside the guests memory (vmcs area for nested-vmx and hsave area for
> nested-svm). When no vcpu is running anymore this is save.
>
> After migration the information is restored from there before any vcpu
> is started again.
>
> unfreeze_vm(...)
> {
> 	for_each_vcpu(vcpu)
> 		kvm_x86_ops->unfreeze_vcpu(vcpu);
> 	restart_all_vcpus();
> }
>    

This is exactly the ioctl approach, yes?

> In the SVM case this still leaves the problem that the MSR bitmap must
> be read again from guests memory on unfreeze but that is not a real
> problem.
>    

This is easily solved by shadowing the MSR bitmap.  Too bad we have to 
do it, but at least the state isn't hidden in a non-extractable field 
inside the processor.

Zach