On 02/21/2010 05:56 PM, 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.
Simplified, this is
ioctl(vcpu_fd, KVM_VCPU_FREEZE, 0);
no need to involve the entire vm IMO. Since the vcpu thread is issuing
the ioctl, the vcpu isn't running.
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();
}
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.
Or we can add traditional state get/set ioctls.
--
error compiling committee.c: too many arguments to function
--
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
