On 02/21/2010 09:46 AM, Gleb Natapov wrote:
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.
We #vmexit unconditionally; the malicious guest will break if it doesn't
handle INTR intercepts even when it did not enable them, but migration
will succeed.
Relying on vcpu state controllable by a guest for migration is not a
good idea.
I agree, but that is not the case here. Regardless, I'd prefer to
migrate the guest in its original state (and not force a #vmexit), so
long as it isn't horribly complicated.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
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
