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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
