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

[Samuel Thibault]

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é <address@hidden> 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.

Samuel