Re: Nested SVM and migration

Zachary Amsden
2010-02-22T16:56:32Z

On 02/21/2010 05:56 AM, 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.
>
> 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();
> }
>

This is exactly the ioctl approach, yes?

> 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.
>

This is easily solved by shadowing the MSR bitmap. Too bad we have to
do it, but at least the state isn't hidden in a non-extractable field
inside the processor.

Zach