On 19.12.2017 18:26, Jim Mattson wrote: > Yes, it can be done that way, but what makes this approach technically > superior to the original API? a) not having to migrate data twice b) not having to think about a proper API to get data in/out All you need to know is, if the guest was in nested mode when migrating, no? That would be a simple flag. > > 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 -- Thanks, David / dhildenb
