On Tue, May 24, 2011 at 02:09:00PM +0300, Avi Kivity wrote:
> On 05/23/2011 09:06 PM, Alexander Graf wrote:
>> On 23.05.2011, at 17:23, Avi Kivity wrote:
>>
>> > On 05/23/2011 05:44 PM, Nadav Har'El wrote:
>> >> On Mon, May 23, 2011, Avi Kivity wrote about "Re: [PATCH 0/30] nVMX:
>> >> Nested VMX, v9":
>> >> > vmcs01 and vmcs02 will both be generated from vmcs12.
>> >>
>> >> If you don't do a clean nested exit (from L2 to L1), vmcs02 can't be
>> >> generated
>> >> from vmcs12... while L2 runs, it is possible that it modifies vmcs02
>> >> (e.g.,
>> >> non-trapped bits of guest_cr0), and these modifications are not copied
>> >> back
>> >> to vmcs12 until the nested exit (when prepare_vmcs12() is called to
>> >> perform
>> >> this task).
>> >>
>> >> If you do a nested exit (a "fake" one), vmcs12 is made up to date, and
>> >> then
>> >> indeed vmcs02 can be thrown away and regenerated.
>> >
>> > You would flush this state back to the vmcs. But that just confirms
>> > Joerg's statement that a fake vmexit/vmrun is more or less equivalent.
>> >
>> > The question is whether %rip points to the VMRUN/VMLAUNCH instruction,
>> > HOST_RIP (or the next instruction for svm), or to guest code. But the
>> > actual things we need to do are all very similar subsets of a vmexit.
>>
>> %rip should certainly point to VMRUN. That way there is no need to save any
>> information whatsoever, as the VMCB is already in sane state and nothing
>> needs to be special cased, as the next VCPU_RUN would simply go back into
>> guest mode - which is exactly what we want.
>>
>> The only tricky part is how we distinguish between "I need to live migrate"
>> and "info registers". In the former case, %rip should be on VMRUN. In the
>> latter, on the guest rip.
>
> We can split vmrun emulation into "save host state, load guest state"
> and "prepare nested vmcb". Then, when we load registers, if we see that
> we're in guest mode, we do just the "prepare nested vmcb" bit.
Or we just emulate a VMEXIT in the VCPU_FREEZE ioctl and set the
%rip back to the VMRUN that entered the L2 guest. For 'info registers'
the VCPU_FREEZE ioctl will not be issued and the guest registers be
displayed.
That way we don't need to migrate any additional state for SVM.
Joerg
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
