Re: [Qemu-devel] [PATCH 1/1] RFC: net/slirp: link with libslirp

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Feb 11, 2019 at 11:22:27PM +0100, Samuel Thibault wrote:
> Marc-André Lureau, le lun. 11 févr. 2019 12:34:47 +0100, a ecrit:
> > On Mon, Feb 11, 2019 at 12:09 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> > >
> > > On Fri, Feb 08, 2019 at 07:12:26PM +0100, Marc-André Lureau wrote:
> > > > Once libslirp has received its first release, we can link with the
> > > > external libslirp library.
> > > >
> > > > The migration data should be compatible with current and older qemu
> > > > versions (same compatibility as today). See "slirp: add state
> > > > saving/loading" patch. However, the content should be treated as a
> > > > blob, as the format may change eventually in the future.
> > >
> > > How are we going to manage live migration compat if libslirp changes
> > > the blob content ?
> > >
> > > Bear in mind that we need to support all existing QEMU releases live
> > > migrating to effectively all future QEMU releases, with all future
> > > libslirp releases, in *both* directions. ie arbitrarily newer
> > > libslirp needs to be able to emit a blob format that can be read
> > > by arbitrarily older slirp inside QEMU.
> > 
> > Right, this is all supported currently with the proposed patch set,
> > since it is effectively the same code.
> > 
> > So register_savevm_live() get passed slirp_state_version() (currently == 4)
> > 
> > & slirp_state_load() get the version_id from QEMU.
> 
> Mmm, but do we guarantee that the current version of slirp will be able
> to read blobs produced by future versions of slirp?
> 
> Future extensions of the format would have to be so that the current
> version could discard their content without issues.
> 
> Perhaps qemu should actually explicitly pass 4 to
> register_savevm_live(), for that function to only record that format
> (and thus get compatibility of course) and only bump to greater values
> when qemu is modified to make use of a functionality which requires
> extending the blob format, which then makes it unreadable by older qemu
> releases, but that is fine for qemu.

If QEMU wants to make use of functionality that requires the new blob
format, it would have to restrict that based on machine type. That way
it can ensure full compatibility with old  QEMU.

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 :|