Re: [PATCH 0/30] nVMX: Nested VMX, v9

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


Alex

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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux