From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk1vE-0008IZ-MA for qemu-devel@nongnu.org; Wed, 14 Sep 2016 00:35:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bk1vA-0000Pu-9U for qemu-devel@nongnu.org; Wed, 14 Sep 2016 00:35:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk1v9-0000Pa-SS for qemu-devel@nongnu.org; Wed, 14 Sep 2016 00:35:40 -0400 Date: Wed, 14 Sep 2016 07:35:36 +0300 From: "Michael S. Tsirkin" Message-ID: <20160914073510-mutt-send-email-mst@kernel.org> References: <75670f77-d788-7217-52a3-f086061fcb78@gameservers.com> <248d9b16-a4a4-1d69-2336-5be86dcd6c20@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <248d9b16-a4a4-1d69-2336-5be86dcd6c20@redhat.com> Subject: Re: [Qemu-devel] qemu 2.7.0 incompatible with host kernel < 3.19 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: Brian Rak , qemu-devel@nongnu.org, Cornelia Huck 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 > Date: Fri Oct 24 14:25:03 2014 +0300 > > vhost/net: enable virtio 1.0 > > Signed-off-by: Michael S. Tsirkin > > 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 > 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 > > 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