Yes, it can be done that way, but what makes this approach technically superior to the original API? On Tue, Dec 19, 2017 at 2:35 AM, David Hildenbrand <david@xxxxxxxxxx> wrote: > On 19.12.2017 04:07, Jim Mattson wrote: >> The other unfortunate thing about flushing the "current" VMCS12 state >> to guest memory on each L2->userspace transition is that much of this >> state is in the VMCS02. So,it's not just a matter of writing a >> VMCS12_SIZE blob to guest memory; first, the cached VMCS12 has to be >> updated from the VMCS02 by calling sync_vmcs12(). This will be >> particularly bad for double-nesting, where L1 kvm has to take all of >> those VMREAD VM-exits. >> >> If you still prefer this method, I will go ahead and do it, but I >> remain opposed. > > This can be easily solved by letting QEMU trigger a pre-migration ioctl. > (FLUSH_NESTED_VMCS). So that shouldn't really be the problem. > > -- > > Thanks, > > David / dhildenb
