> Quoting Michael Roth (2016-12-14 10:02:15)
> > Quoting Michael S. Tsirkin (2016-12-14 09:15:38)
> > > On Wed, Dec 14, 2016 at 09:08:52AM -0600, Michael Roth wrote:
> > > > Quoting Maxime Coquelin (2016-12-14 06:52:37)
> > > > > This patch fixes a cross-version migration regression introduced
> > > > > by commit d1b4259f ("virtio-bus: Plug devices after features are
> > > > > negotiated").
> > > > >
> > > > > The problem is encountered when host's vhost backend does not support
> > > > > VIRTIO_F_VERSION_1, and migration is initiated from a v2.7 or prior
> > > > > machine with virtio-pci modern capabilities enabled to a v2.8 machine.
> > > > >
> > > > > In this case, modern capabilities get exposed to the guest by the
source,
> > > > > whereas the target will detect version 1 is not supported so will only
> > > > > expose legacy capabilities.
> > > > >
> > > > > The problem is fixed by introducing a new "x-modern-broken" property,
> > > > > which is set in v2.7 and prior compatibility modes. Doing this, v2.7
> > > > > machine keeps its broken behaviour (enabling modern while version is
> > > > > not supported), and newer machines will behave correctly.
> > > > >
> > > > > Reported-by: Michael Roth <address@hidden>
> > > > > Suggested-by: Stefan Hajnoczi <address@hidden>
> > > > > Cc: Michael S. Tsirkin <address@hidden>
> > > > > Cc: Cornelia Huck <address@hidden>
> > > > > Cc: Marcel Apfelbaum <address@hidden>
> > > > > Cc: Dr. David Alan Gilbert <address@hidden>
> > > > > Signed-off-by: Maxime Coquelin <address@hidden>
> > > >
> > > > Tested-by: Michael Roth <address@hidden>
> > > >
> > > > I can confirm this fixes the original issue I reported. I also did a
> > > > number of sanity runs with 2.7/2.8/pc-i440fx-2.{6,7,8} using various
> > > > combinations of disable-modern=true/false on hosts with/without
virtio-1,
> > > > and some tests with pseries machines as well, and everything seems to
> > > > work.
> > > >
> > > > Thanks for the quick fix!
> > >
> > > FYI what I think does not work is a recent kernel on 2.7
> > > machine type and host without virtio 1.
> > > But this is not new.
> >
> > To clarify I was only testing migration compatibility, I assume virtio
> > on 2.7 machines is still broken for the configuration you mentioned.
> >
> > The migration tests I ran on the virtio-1 host do cover networking over
> > a virtio-net device before/after migration with reboots before/after
> > migration as well though, and the guest in those cases had a 4.8 kernel,
> > so I think the sanity checks I mentioned also apply for confirming
> > virtio-net probe is succeeding in the guest.
> >
> > The non-virtio-1 runs are being done on my local machine and the tests
> > in that case are a bit more basic and don't involve actively testing
> > networking. I'll try some manual tests to check this. I guess the main
> > things to confirm on that front are that after the patch virtio probing:
> >
> > pc-i440fx-2.6, defaults -> succeeds
> > pc-i440fx-2.6, disable-modern=true -> succeeds
> > pc-i440fx-2.6, disable-modern=false -> fails
> >
> > pc-i440fx-2.7, defaults -> fails
> > pc-i440fx-2.7, disable-modern=true -> succeeds
> > pc-i440fx-2.7, disable-modern=false -> fails
> >
> > pc-i440fx-2.8, defaults -> succeeds
> > pc-i440fx-2.8, disable-modern=true -> succeeds
> > pc-i440fx-2.8, disable-modern=false -> succeeds
>
> I wasn't able to test disable-modern with pc-i440fx-2.6 due to the issue
> being fixes by proposed patch "machine: Convert abstract typename on
> compat_props to subclass names", but I think the rest of the cases align
> with expectations:
>
> 2.6, defaults: succeeds
>
> 2.7, defaults: fails
> 2.7, disable-modern=true: succeeds
> 2.7, disable-modern=false: fails
>
> 2.8, defaults: succeeds
> 2.7, disable-modern=true: succeeds
> 2.7, disable-modern=false: succeeds