Re: Nested SVM and migration

[Gleb Natapov <gleb@redhat.com>]

On Sun, Feb 21, 2010 at 09:23:40AM +0200, Avi Kivity wrote:
> On 02/20/2010 10:18 PM, Joerg Roedel wrote:
> >
> >>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?
> 
> This doesn't work if the guest disables INTR intercepts, or if the
> guest checks that an interrupt was actually received.  Of course no
> sane guest does this.
> 
Malicious guest may do this on purpose just to prevent migration.
Relying on vcpu state controllable by a guest for migration is not a
good idea.

--
			Gleb.