From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Samuel Thibault <samuel.thibault@gnu.org>
Cc: "Daniel P. Berrange" <berrange@redhat.com>,
Juan Quintela <quintela@redhat.com>,
qemu-devel@nongnu.org, jan.kiszka@siemens.com,
maethor@subiron.org
Subject: Re: [Qemu-devel] [PATCH v4 4/5] slirp: VMStatify socket level
Date: Tue, 28 Feb 2017 16:54:46 +0000 [thread overview]
Message-ID: <20170228165445.GG2773@work-vm> (raw)
In-Reply-To: <20170226203427.6xjmuvt6okc356e5@var.youpi.perso.aquilenet.fr>
* Samuel Thibault (samuel.thibault@gnu.org) wrote:
> Hello,
>
> Dr. David Alan Gilbert, on jeu. 23 févr. 2017 11:40:45 +0000, wrote:
> > * Daniel P. Berrange (berrange@redhat.com) 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 / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2017-02-28 16:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-20 18:50 [Qemu-devel] [PATCH v4 0/5] SLIRP VMStatification Dr. David Alan Gilbert (git)
2017-02-20 18:50 ` [Qemu-devel] [PATCH v4 1/5] slirp: VMState conversion; tcpcb Dr. David Alan Gilbert (git)
2017-02-20 18:50 ` [Qemu-devel] [PATCH v4 2/5] slirp: VMStatify sbuf Dr. David Alan Gilbert (git)
2017-02-20 18:50 ` [Qemu-devel] [PATCH v4 3/5] slirp: Common lhost/fhost union Dr. David Alan Gilbert (git)
2017-02-20 21:02 ` Philippe Mathieu-Daudé
2017-02-21 13:55 ` Juan Quintela
2017-02-20 18:50 ` [Qemu-devel] [PATCH v4 4/5] slirp: VMStatify socket level Dr. David Alan Gilbert (git)
2017-02-21 14:03 ` Juan Quintela
2017-02-21 14:08 ` Dr. David Alan Gilbert
2017-02-23 10:51 ` Dr. David Alan Gilbert
2017-02-23 11:04 ` Daniel P. Berrange
2017-02-23 11:40 ` Dr. David Alan Gilbert
2017-02-26 20:34 ` Samuel Thibault
2017-02-26 22:59 ` Samuel Thibault
2017-02-28 16:54 ` Dr. David Alan Gilbert [this message]
2017-02-28 16:57 ` Samuel Thibault
2017-02-28 17:00 ` Dr. David Alan Gilbert
2017-02-28 17:02 ` Samuel Thibault
2017-02-28 17:09 ` Dr. David Alan Gilbert
2017-02-28 17:12 ` Samuel Thibault
2017-02-28 17:40 ` Dr. David Alan Gilbert
2017-02-28 22:09 ` Samuel Thibault
2017-02-20 18:50 ` [Qemu-devel] [PATCH v4 5/5] slirp: VMStatify remaining except for loop Dr. David Alan Gilbert (git)
2017-02-21 13:57 ` Juan Quintela
2017-02-20 19:02 ` [Qemu-devel] [PATCH v4 0/5] SLIRP VMStatification no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170228165445.GG2773@work-vm \
--to=dgilbert@redhat.com \
--cc=berrange@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=maethor@subiron.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=samuel.thibault@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).