qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [QEMU PATCH v2 0/2]: KVM: i386: Add support for save an


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [QEMU PATCH v2 0/2]: KVM: i386: Add support for save and restore nested state
Date: Fri, 2 Nov 2018 16:58:07 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

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 <address@hidden> 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 ?

There are a bunch of features in QEMU's migration code which require
the mgmt layer to look at source + dest to determine what should be
done. Admittedly the cases we have had so far are generic migration
features (compression, multifd, postcopy, TLS, etc), while this is
a host kernel feature. I don't think it is that far outside the
normal practice wrt migration feature usage decision making though.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]