From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48043) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8rlJ-00024s-Ng for qemu-devel@nongnu.org; Mon, 21 Nov 2016 11:48:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8rlE-0006cp-Md for qemu-devel@nongnu.org; Mon, 21 Nov 2016 11:48:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39718) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c8rlE-0006cj-CZ for qemu-devel@nongnu.org; Mon, 21 Nov 2016 11:48:04 -0500 Date: Mon, 21 Nov 2016 18:48:02 +0200 From: "Michael S. Tsirkin" Message-ID: <20161121184537-mutt-send-email-mst@kernel.org> References: <1479419887-10515-1-git-send-email-maxime.coquelin@redhat.com> <1479419887-10515-4-git-send-email-maxime.coquelin@redhat.com> <20161118003558-mutt-send-email-mst@kernel.org> <3120fbd4-99eb-a9f2-a2b3-a5f686dbc7ee@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3120fbd4-99eb-a9f2-a2b3-a5f686dbc7ee@redhat.com> Subject: Re: [Qemu-devel] [RFC v2 3/3] virtio-net: Add MTU feature support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Maxime Coquelin Cc: aconole@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, jasowang@redhat.com, yuanhan.liu@linux.intel.com On Mon, Nov 21, 2016 at 01:34:32PM +0100, Maxime Coquelin wrote: > > > On 11/17/2016 11:38 PM, Michael S. Tsirkin wrote: > > On Thu, Nov 17, 2016 at 10:58:07PM +0100, Maxime Coquelin wrote: > > > If negotiated, virtio-net gets the advised MTU from vhost-net, > > > and provides it to the guest through a new virtio_net_config > > > entry. > > > > > > Cc: Michael S. Tsirkin > > > Cc: Aaron Conole > > Signed-off-by: Maxime Coquelin > > > --- > > > hw/net/virtio-net.c | 14 ++++++++++++++ > > > include/hw/virtio/virtio-net.h | 1 + > > > 2 files changed, 15 insertions(+) > > > > > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c > > > index 5009533..36843fe 100644 > > > --- a/hw/net/virtio-net.c > > > +++ b/hw/net/virtio-net.c > > > @@ -55,6 +55,8 @@ static VirtIOFeature feature_sizes[] = { > > > .end = endof(struct virtio_net_config, status)}, > > > {.flags = 1 << VIRTIO_NET_F_MQ, > > > .end = endof(struct virtio_net_config, max_virtqueue_pairs)}, > > > + {.flags = 1 << VIRTIO_NET_F_MTU, > > > + .end = endof(struct virtio_net_config, mtu)}, > > > {} > > > }; > > > > > > @@ -81,6 +83,7 @@ static void virtio_net_get_config(VirtIODevice *vdev, uint8_t *config) > > > > > > virtio_stw_p(vdev, &netcfg.status, n->status); > > > virtio_stw_p(vdev, &netcfg.max_virtqueue_pairs, n->max_queues); > > > + virtio_stw_p(vdev, &netcfg.mtu, n->mtu); > > > memcpy(netcfg.mac, n->mac, ETH_ALEN); > > > memcpy(config, &netcfg, n->config_size); > > > } > > > @@ -636,6 +639,14 @@ static void virtio_net_set_features(VirtIODevice *vdev, uint64_t features) > > > } else { > > > memset(n->vlans, 0xff, MAX_VLAN >> 3); > > > } > > > + > > > + if (virtio_has_feature(features, VIRTIO_NET_F_MTU)) { > > > + NetClientState *nc = qemu_get_queue(n->nic); > > > + > > > + if (get_vhost_net(nc->peer)) { > > > + n->mtu = vhost_net_get_mtu(get_vhost_net(nc->peer)); > > > > > > This means migration breaks silently if you move from a bigger to > > smaller mtu. We don't necessarily have to make it work, > > but it should be detected and reported. > > Good point. > I planned to investigate migration case while looking deeper at > vhost-user versionning topic. > > Moving from bigger to smaller MTU is indeed a problem, because the > backend may not support received buffer size. > > Isn't also a problem when moving from smaller to bigger MTU, as it no > more respect the contract old host negotiated with the guest? Depends on what assumptions backends makes, but generally yes. > > > > > + } > > > + } > > > } > > > > > > static int virtio_net_handle_rx_mode(VirtIONet *n, uint8_t cmd, > > > > What about non-vhost traffic? You need to ensure guest does > > not get bigger packets. > Ok, do you confirm checking in virtio_net_receive() that buffer size is > smaller or equal than MTU is enough? > > > > > > > > @@ -1695,6 +1706,7 @@ static void virtio_net_set_config_size(VirtIONet *n, uint64_t host_features) > > > { > > > int i, config_size = 0; > > > virtio_add_feature(&host_features, VIRTIO_NET_F_MAC); > > > + virtio_add_feature(&host_features, VIRTIO_NET_F_MTU); > > > for (i = 0; feature_sizes[i].flags != 0; i++) { > > > if (host_features & feature_sizes[i].flags) { > > > config_size = MAX(feature_sizes[i].end, config_size); > > > @@ -1922,6 +1934,8 @@ static Property virtio_net_properties[] = { > > > DEFINE_PROP_STRING("tx", VirtIONet, net_conf.tx), > > > DEFINE_PROP_UINT16("rx_queue_size", VirtIONet, net_conf.rx_queue_size, > > > VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE), > > > + DEFINE_PROP_BIT("host_mtu", VirtIONet, host_features, > > > + VIRTIO_NET_F_MTU, true), > > > DEFINE_PROP_END_OF_LIST(), > > > }; > > > > > > > Cross version migration support is missing here. > Sorry, I'm not sure to understand what you expect here. > Could you please provide more details? feature bits must be consistent for a given machine type. So you can't add them unconditionally for old machine types, they must look the same as they looked when we put that machine type out. > > > > > diff --git a/include/hw/virtio/virtio-net.h b/include/hw/virtio/virtio-net.h > > > index 0ced975..b6394c8 100644 > > > --- a/include/hw/virtio/virtio-net.h > > > +++ b/include/hw/virtio/virtio-net.h > > > @@ -96,6 +96,7 @@ typedef struct VirtIONet { > > > QEMUTimer *announce_timer; > > > int announce_counter; > > > bool needs_vnet_hdr_swap; > > > + uint16_t mtu; > > > } VirtIONet; > > > > > > void virtio_net_set_netclient_name(VirtIONet *n, const char *name, > > > -- > > > 2.7.4 > > Thanks, > Maxime