On 19/12/2017 20:21, Jim Mattson wrote: > One reason is that it is a bit awkward for GET_NESTED_STATE to modify > guest memory. I don't know about qemu, but our userspace agent expects > guest memory to be quiesced by the time it starts going through its > sequence of GET_* ioctls. Sure, we could introduce a pre-migration > ioctl, but is that the best way to handle this? Another reason is that > it is a bit awkward for SET_NESTED_STATE to require guest memory. > Again, I don't know about qemu, but our userspace agent does not > expect any guest memory to be available when it starts going through > its sequence of SET_* ioctls. Sure, we could prefetch the guest page > containing the current VMCS12, but is that better than simply > including the current VMCS12 in the NESTED_STATE payload? Moreover, > these unpredictable (from the guest's point of view) updates to guest > memory leave a bad taste in my mouth (much like SMM). IIRC QEMU has no problem with either, but I think your concerns are valid. The active VMCS is processor state, not memory state. Same for the host save data in SVM. The unstructured "blob" of data is not an issue. If it becomes a problem, we can always document the structure... Paolo > > Perhaps qemu doesn't have the same limitations that our userspace > agent has, and I can certainly see why you would dismiss my concerns > if you are only interested in qemu as a userspace agent for kvm. At > the same time, I hope you can understand why I am not excited to be > drawn down a path that's going to ultimately mean more headaches for > me in my environment. AFAICT, the proposed API doesn't introduce any > additional headaches for those that use qemu. The principal objections > appear to be the "blob" of data, completely unstructured in the eyes > of the userspace agent, and the redundancy with state already > extracted by existing APIs. Is that right? > > > On Tue, Dec 19, 2017 at 9:40 AM, David Hildenbrand <david@xxxxxxxxxx> wrote: >> On 19.12.2017 18:33, David Hildenbrand wrote: >>> 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. >>> >> >> (of course in addition, vmcsptr and if vmxon has been called). >> >> But anyhow, if you have good reasons why you want to introduce and >> maintain a new API, feel free to do so. Most likely I am missing >> something important here :) >> >> >> -- >> >> Thanks, >> >> David / dhildenb
