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.
This way register state is always nested guest state. -- 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
