From patchwork Mon Feb 4 06:41:43 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Michael S. Tsirkin" X-Patchwork-Id: 217834 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id D87DE2C02A4 for ; Mon, 4 Feb 2013 17:38:08 +1100 (EST) Received: from localhost ([::1]:56379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2Fgt-0006nr-2j for incoming@patchwork.ozlabs.org; Mon, 04 Feb 2013 01:38:07 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2FgJ-0006nh-5V for qemu-devel@nongnu.org; Mon, 04 Feb 2013 01:37:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U2FgG-00049a-HS for qemu-devel@nongnu.org; Mon, 04 Feb 2013 01:37:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U2FgG-00049W-9g for qemu-devel@nongnu.org; Mon, 04 Feb 2013 01:37:28 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r146bQ9Z006254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Feb 2013 01:37:26 -0500 Received: from redhat.com (vpn1-4-137.ams2.redhat.com [10.36.4.137]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id r146bM4N007980; Mon, 4 Feb 2013 01:37:23 -0500 Date: Mon, 4 Feb 2013 08:41:43 +0200 From: "Michael S. Tsirkin" To: Anthony Liguori Message-ID: <20130204064143.GB329@redhat.com> References: <510C28BD.7050701@msgid.tls.msk.ru> <87zjznagbd.fsf@codemonkey.ws> <510D09C2.6050905@redhat.com> <1359835708.1968.3.camel@localhost> <87halu1fic.fsf@codemonkey.ws> <401C01B3-F93C-4804-8208-D1D6F62285AC@redhat.com> <510E8BD4.9000505@msgid.tls.msk.ru> <87vca9gl4c.fsf@codemonkey.ws> <20130203222246.GA21229@redhat.com> <871ucx3t0d.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <871ucx3t0d.fsf@codemonkey.ws> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: Rusty Russell , Jason Wang , Yan Vugenfirer , Michael Tokarev , qemu-devel , Vadim Rozenfeld Subject: Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Sun, Feb 03, 2013 at 04:57:38PM -0600, Anthony Liguori wrote: > "Michael S. Tsirkin" writes: > > > On Sun, Feb 03, 2013 at 03:09:39PM -0600, Anthony Liguori wrote: > >> Michael Tokarev writes: > >> > >> > 03.02.2013 17:23, Yan Vugenfirer wrote: > >> > > >> >>> If it helps, mq changes the config size from 8 to 16 bytes. If the > >> >>> driver was making an assumption about an 8-byte config size, that's > >> >>> likely what the problem is. > >> >>> > >> >> That's exactly the problem. > >> > > >> > So what do we do? It isn't nice to break existing setups. > >> > Maybe mq can be disabled by default (together with Antony's > >> > patch) until fixed drivers will be more widely available? > >> > >> I've got a patch that does exactly like this. It's pretty ugly though > >> because of the relationship between virtio-pci and virtio-net. I'm > >> going to try to see if I can find a cleaner way to do it on Monday. > >> > >> I'm also contemplating just disabling mq by default. Since a special > >> command line is needed to enable it anyway (on the backend), having to > >> specify mq=on for the device doesn't seem so bad. > > > > > > It's after midnight here so didn't test yet, but wouldn't the following > > achieve this in a way that is a bit cleaner? > > > > Signed-off-by: Michael S. Tsirkin > > > > > > diff --git a/hw/virtio-net.c b/hw/virtio-net.c > > index 5699f5e..3342a76 100644 > > --- a/hw/virtio-net.c > > +++ b/hw/virtio-net.c > > @@ -346,6 +346,10 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev, uint32_t features) > > > > features |= (1 << VIRTIO_NET_F_MAC); > > > > + if (n->max_queues <= 1) { > > + features &= ~(0x1 << VIRTIO_NET_F_MQ); > > + } > > + > > This is too late because the config size has already been set. > > > if (!peer_has_vnet_hdr(n)) { > > features &= ~(0x1 << VIRTIO_NET_F_CSUM); > > features &= ~(0x1 << VIRTIO_NET_F_HOST_TSO4); > > @@ -1284,7 +1288,9 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf, > > int i; > > > > n = (VirtIONet *)virtio_common_init("virtio-net", VIRTIO_ID_NET, > > - sizeof(struct virtio_net_config), > > + conf->queues > 1 ? > > + sizeof(struct virtio_net_config) : > > + sizeof(struct virtio_net_config_compat), > > sizeof(VirtIONet)); > > This makes me a bit nervous. It relies on setting the config size to > one thing before we've masked a feature. > > What do you think about just defaulting mq=off? The more I think about > it, the nicer of an option that is. > > I'm not a huge fan of automagically changing the value of a feature bit > so I think defaulting it off is a bit more straight forward. > > We can certainly revisit for 1.5+. > > Regards, > > Anthony Liguori Thinking about it some more, we have the queues option so adding an mq option as well is not useful. Let's clear it unless # of queues is set? What do you think about the below? This time tested with an sq guest but not an mq guest yet. Signed-off-by: Michael S. Tsirkin diff --git a/hw/virtio-net.c b/hw/virtio-net.c index 5699f5e..b8c8439 100644 --- a/hw/virtio-net.c +++ b/hw/virtio-net.c @@ -346,6 +346,10 @@ static uint32_t virtio_net_get_features(VirtIODevice *vdev, uint32_t features) features |= (1 << VIRTIO_NET_F_MAC); + if (n->max_queues > 1) { + features |= (0x1 << VIRTIO_NET_F_MQ); + } + if (!peer_has_vnet_hdr(n)) { features &= ~(0x1 << VIRTIO_NET_F_CSUM); features &= ~(0x1 << VIRTIO_NET_F_HOST_TSO4); @@ -1284,7 +1288,9 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf, int i; n = (VirtIONet *)virtio_common_init("virtio-net", VIRTIO_ID_NET, - sizeof(struct virtio_net_config), + conf->queues > 1 ? + sizeof(struct virtio_net_config) : + sizeof(struct virtio_net_config_compat), sizeof(VirtIONet)); n->vdev.get_config = virtio_net_get_config; diff --git a/hw/virtio-net.h b/hw/virtio-net.h index 1d5c721..19f63cf 100644 --- a/hw/virtio-net.h +++ b/hw/virtio-net.h @@ -69,6 +69,14 @@ typedef struct virtio_net_conf /* Maximum packet size we can receive from tap device: header + 64k */ #define VIRTIO_NET_MAX_BUFSIZE (sizeof(struct virtio_net_hdr) + (64 << 10)) +struct virtio_net_config_compat +{ + /* The config defining mac address ($ETH_ALEN bytes) */ + uint8_t mac[ETH_ALEN]; + /* See VIRTIO_NET_F_STATUS and VIRTIO_NET_S_* above */ + uint16_t status; +} QEMU_PACKED; + struct virtio_net_config { /* The config defining mac address ($ETH_ALEN bytes) */ @@ -190,6 +199,5 @@ struct virtio_net_ctrl_mq { DEFINE_PROP_BIT("ctrl_rx", _state, _field, VIRTIO_NET_F_CTRL_RX, true), \ DEFINE_PROP_BIT("ctrl_vlan", _state, _field, VIRTIO_NET_F_CTRL_VLAN, true), \ DEFINE_PROP_BIT("ctrl_rx_extra", _state, _field, VIRTIO_NET_F_CTRL_RX_EXTRA, true), \ - DEFINE_PROP_BIT("ctrl_mac_addr", _state, _field, VIRTIO_NET_F_CTRL_MAC_ADDR, true), \ - DEFINE_PROP_BIT("mq", _state, _field, VIRTIO_NET_F_MQ, true) + DEFINE_PROP_BIT("ctrl_mac_addr", _state, _field, VIRTIO_NET_F_CTRL_MAC_ADDR, true) #endif