On Fri, Nov 2, 2018 at 9:58 AM, Daniel P. Berrangé <berra...@redhat.com> wrote: > On Fri, Nov 02, 2018 at 09:44:54AM -0700, Jim Mattson via Qemu-devel wrote: >> On Fri, Nov 2, 2018 at 5:59 AM, Liran Alon <liran.a...@oracle.com> wrote: >> > >> >> >>> Therefore, I don't think that we want this versioning to be based on >> >>> KVM_CAP at all. >> >>> It seems that we would want the process to behave as follows: >> >>> 1) Mgmt-layer at dest queries dest host max supported nested_state size. >> >>> (Which should be returned from >> >>> kvm_check_extension(KVM_CAP_NESTED_STATE)) >> >>> 2) Mgmt-layer at source initiate migration to dest with requesting QEMU >> >>> to send nested_state >> >>> matching dest max supported nested_state size. >> >>> When saving nested state using KVM_GET_NESTED_STATE IOCTL, QEMU will >> >>> specify in nested_state->size >> >>> the *requested* size to be saved and KVM should be able to save only >> >>> the information which matches >> >>> the version that worked with that size. >> >>> 3) After some sanity checks on received migration stream, dest host use >> >>> KVM_SET_NESTED_STATE IOCTL. >> >>> This IOCTL should deduce which information it should deploy based on >> >>> given nested_state->size. >> >> I have to object to any proposal which requires the management later >> to communicate with the source and the destination to determine what >> should be done. > > Can you elaborate on why you object ?
We don't currently have this requirement, and I don't want to be encumbered by it.
