On Fri, 11 Sep 2015 10:30:21 +0200
Cornelia Huck <cornelia.h...@de.ibm.com> wrote:
> On Fri, 11 Sep 2015 16:01:56 +0800
> Jason Wang <jasow...@redhat.com> wrote:
>
> > After commit 019a3edbb25f1571e876f8af1ce4c55412939e5d ("virtio: make
> > features 64bit wide"). Device's guest_features was actually set after
> > vdc->load(). This breaks the assumption that device specific load()
> > function can check guest_features. For virtio-net, self announcement
> > and guest offloads won't work after migration.
> >
> > Fixing this by defer them to virtio_net_load() where guest_features
> > were guaranteed to be set. Other virtio devices looks fine.
> >
> > Fixes: 019a3edbb25f1571e876f8af1ce4c55412939e5d
> > ("virtio: make features 64bit wide")
> > Cc: qemu-sta...@nongnu.org
> > Cc: Gerd Hoffmann <kra...@redhat.com>
> > Signed-off-by: Jason Wang <jasow...@redhat.com>
> > ---
> > hw/net/virtio-net.c | 40 +++++++++++++++++++++++-----------------
> > 1 file changed, 23 insertions(+), 17 deletions(-)
>
> Migration support for virtio is really a twisty maze, it's easy to make
> mistakes like that :(
>
We have the very same problem with @device_endian which is also streamed in
a subsection. To prevent early usage on the load path, we set @device_endian
to a poisoned value that triggers assert() in the virtio_is_big_endian() helper.
Should this logic be generalized ?
