qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 4/5] slirp: VMStatify socket level


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v4 4/5] slirp: VMStatify socket level
Date: Tue, 28 Feb 2017 16:54:46 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

* Samuel Thibault (address@hidden) wrote:
> Hello,
> 
> Dr. David Alan Gilbert, on jeu. 23 févr. 2017 11:40:45 +0000, wrote:
> > * Daniel P. Berrange (address@hidden) wrote:
> > > IOW if we transmit this data on the wire, we've effectively said that
> > > our migration data format is *not* portable across different host OS
> > > platforms. At that point, sending different sized types on BSD vs
> > > Linux is no big deal since we're already incompatible semantically.
> > 
> > This is a relatively recent error; it comes from eae303ff which added
> > ss_family to allow IPv6.
> > 
> > I suspect the right fix here is to populate a temporary for ss_family
> > on the wire; if we make it conveniently match Linux's AF_INET6 values
> > it might work.
> 
> So this issue is actually not new, so I asked to pull your patch series,
> thanks!

It is because the old non-vmstate code just truncated the value read,
where as the VMSTATE macros have strong type checks.

> Now we should indeed fix the issue. Making the values match Linux'
> AF_INET6, why not (better have some known values than arbitrary values),
> but I don't think we'd want to rely on this: we'll have to introduce a
> versioned difference, since we'll want to change the size of the field
> as well as its value on other OSes (and I don't think we want to manage
> different versioning on different OSes).

> Ah, no, sorry, it was forced to be 16bit, so at least the size is fine.
> 
> But I guess we don't want to change the values to have cross-OS
> compatibility without changing the version.

I'm thinking one way to do it without changing the version would
be to use the existing value for IPv4, and on reading allow any other
value for IPv6 (or just the ones we know about); that would make
it inwards migration compatible.  For writing we pick one for IPv6
and stick to it.

Dave

> 
> Samuel
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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