Re: Nested SVM and migration

[Joerg Roedel <joro@8bytes.org>]

On Sat, Feb 20, 2010 at 09:14:06AM -1000, Zachary Amsden wrote:
> Perhaps I am misunderstanding, but I don't see how nested SVM instances  
> can be properly migrated.  How does one extract and rebuild the nested  
> hsave control block?

Migrating guests which run in nested mode could not be migrated in a
save way currently but there are plans to fix that :-)
The first step is to save the l1 cpu state in the guest supplied hsave
area. But that is not sufficient because this does not work for all l1
state.

> If it isn't done already, one possible way to add it as an extension  
> might be to represent the data as additional MSRs which are saved and  
> restored with migration.

This sounds complicated.

> Actually, looking deeper, there doesn't even appear to be any way to  
> export the nested CPU data at all, meaning basic features like  
> suspending and restoring the VM are not possible.  Is there any plan to  
> make it work in the near future?  I'm not complaining; if my  
> understanding is correct, this actually makes my current task easier.

I think we should introduce a flag to indicate userspace if a vcpu is in
a state that could be migrated in a save way together with a way for
userspace to request that the vcpu enters a migratable state. In the
kernel we could do something like that:

nested_svm_vmrun(...)
{
	/* ... */
	kvm_migration_disable(vcpu);
	/* ... */
}

nested_svm_vmexit(...)
{
	/* ... */
	kvm_migration_enable(vcpu);
	/* ... */
}

and somewhere in the vcpu_run loop:

if (vcpu->arch.migration_win_req)
	nested_svm_vmexit(INTR);

This might be helpful in other situations too. Thoughts?

	Joerg