On Tue, Sep 13, 2016 at 11:09:27PM +0200, Laszlo Ersek wrote:
> Hi,
>
> (CC Michael and Cornelia,)
>
> On 09/13/16 21:10, Brian Rak wrote:
> > I have some KVM hosts that I just upgraded to qemu 2.7.0. When the host
> > is running a kernel newer then 3.19, everything works fine.
> >
> > If the host is running on something lower then 3.19, some guests fail to
> > start. I noticed this on a Ubuntu 16.04 guest, it fails to find the
> > virtio NIC, and this is printed to dmesg:
> >
> > virtio_net virtio0: virtio: device uses modern interface but does not
> > have VIRTIO_F_VERSION_1
> >
> > Looking around, I found
> > https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg00373.html ,
> > but this does not appear to fully resolve the issue. Any suggestions
> > here? I'm currently just rolling back the upgrade until we can get the
> > kernel upgraded on the rest of the hosts.
>
> let me begin with saying that I probably don't know what I'm talking
> about :)
>
> So, based on your report and the message you linked from the archive, I
> think the problem is that vhost-net, in host kernels strictly older than
> v3.19, doesn't set VIRTIO_F_VERSION_1.
>
> See this kernel commit:
>
> commit 41e3e42108bc5ebc77d40d6fe1216c483a6b1f9d
> Author: Michael S. Tsirkin <m...@redhat.com>
> Date: Fri Oct 24 14:25:03 2014 +0300
>
> vhost/net: enable virtio 1.0
>
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
>
> This was first released in v3.19. (See "git tag --contains 41e3e42108bc".)
>
> (
>
> Later this would be moved to a more central location, with:
>
> commit 4e9fa50c6ccbebef0c4a4aae84090badf81359e6
> Author: Michael S. Tsirkin <m...@redhat.com>
> Date: Wed Sep 9 22:24:56 2015 +0300
>
> vhost: move features to core
>
> virtio 1 and any layout are core features, move them
> there. This fixes vhost test.
>
> Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
>
> but this commit was released in v4.3, and I don't think it should make a
> visible difference to your use case.
>
> )
>
> I *guess* that with qemu-2.7.0, any lack of VIRTIO_F_VERSION_1 in the
> host kernel's device model has become visible to the guest, and then the
> guest driver bails out. (I don't know what exactly brought about this
> change in qemu-2.7.0.)
>
> Now, the libvirt documentation says,
>
> http://libvirt.org/formatdomain.html#elementsDriverBackendOptions
>
> [...] Currently the following attributes are available for the
> "virtio" NIC driver:
>
> name
>
> The optional name attribute forces which type of backend driver
> to use. The value can be either 'qemu' (a user-space backend)
> or 'vhost' (a kernel backend, which requires the vhost module
> to be provided by the kernel); an attempt to require the vhost
> driver without kernel support will be rejected. If this
> attribute is not present, then the domain defaults to 'vhost'
> if present, but silently falls back to 'qemu' without error.
>
> So, rather than rolling back the QEMU upgrade, can you test turning off
> vhost in your domain XMLs (or, on the qemu command line, with
>
> -netdev tap,...,vhost=off
>
> ) until you can upgrade the host kernels?
>
> Alternatively, you could rmmod / blacklist the "vhost_net" module on
> your affected hosts. (This would only work if the domain XML doesn't
> explicitly ask for vhost, see above.)
>
> Again, this is just a guess.
>
> Thanks
> Laszlo
This patch:
virtio-bus: Plug devices after features are negotiated
should help I think.
Could you try it please?
--
MST
