From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eX8u9-0002AB-UG for qemu-devel@nongnu.org; Thu, 04 Jan 2018 12:02:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eX8u4-0004uy-IC for qemu-devel@nongnu.org; Thu, 04 Jan 2018 12:02:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31553) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eX8u4-0004uD-A6 for qemu-devel@nongnu.org; Thu, 04 Jan 2018 12:02:04 -0500 Date: Thu, 4 Jan 2018 19:02:01 +0200 From: "Michael S. Tsirkin" Message-ID: <20180104190131-mutt-send-email-mst@kernel.org> References: <20180104182602-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH net-next v3 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jason Baron Cc: davem@davemloft.net, jasowang@redhat.com, netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org On Thu, Jan 04, 2018 at 11:57:44AM -0500, Jason Baron wrote: > > > On 01/04/2018 11:27 AM, Michael S. Tsirkin wrote: > > On Thu, Jan 04, 2018 at 12:16:44AM -0500, Jason Baron wrote: > >> The ability to set speed and duplex for virtio_net is useful in various > >> scenarios as described here: > >> > >> 16032be virtio_net: add ethtool support for set and get of settings > >> > >> However, it would be nice to be able to set this from the hypervisor, > >> such that virtio_net doesn't require custom guest ethtool commands. > >> > >> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows > >> the hypervisor to export a linkspeed and duplex setting. The user can > >> subsequently overwrite it later if desired via: 'ethtool -s'. > >> > >> Note that VIRTIO_NET_F_SPEED_DUPLEX is defined as bit 63, the intention > >> is that device feature bits are to grow down from bit 63, since the > >> transports are starting from bit 24 and growing up. > >> > >> Signed-off-by: Jason Baron > >> Cc: "Michael S. Tsirkin" > >> Cc: Jason Wang > >> Cc: virtio-dev@lists.oasis-open.org > >> --- > >> drivers/net/virtio_net.c | 19 ++++++++++++++++++- > >> include/uapi/linux/virtio_net.h | 13 +++++++++++++ > >> 2 files changed, 31 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > >> index 6fb7b65..0b2d314 100644 > >> --- a/drivers/net/virtio_net.c > >> +++ b/drivers/net/virtio_net.c > >> @@ -2146,6 +2146,22 @@ static void virtnet_config_changed_work(struct work_struct *work) > >> > >> vi->status = v; > >> > >> + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_SPEED_DUPLEX)) { > >> + u32 speed; > >> + u8 duplex; > >> + > >> + speed = virtio_cread32(vi->vdev, > >> + offsetof(struct virtio_net_config, > >> + speed)); > >> + if (ethtool_validate_speed(speed)) > >> + vi->speed = speed; > >> + duplex = virtio_cread8(vi->vdev, > >> + offsetof(struct virtio_net_config, > >> + duplex)); > >> + if (ethtool_validate_duplex(duplex)) > >> + vi->duplex = duplex; > >> + } > >> + > >> if (vi->status & VIRTIO_NET_S_LINK_UP) { > >> netif_carrier_on(vi->dev); > >> netif_tx_wake_all_queues(vi->dev); > >> @@ -2796,7 +2812,8 @@ static struct virtio_device_id id_table[] = { > >> VIRTIO_NET_F_CTRL_RX, VIRTIO_NET_F_CTRL_VLAN, \ > >> VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \ > >> VIRTIO_NET_F_CTRL_MAC_ADDR, \ > >> - VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS > >> + VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \ > >> + VIRTIO_NET_F_SPEED_DUPLEX > >> > >> static unsigned int features[] = { > >> VIRTNET_FEATURES, > > > > Still missing the update from virtnet_config_changed_work, and I think > > it's important to reflex host changes within guest when the > > feature bit has been acked. > > > > I update vi->speed and vi->duplex in virtnet_config_changed_work(). And > I tested using the 'set_link' on/off from the qemu monitor. > Specifically, an 'off' sets the speed and link to 'unknown', and an 'on' > returns the speed and link to the configured speed and duplex. So they > are being updated dynamically now. What host changes are you referring > to that are not reflected? > > Thanks, > > -Jason Ouch, I was reviewing an old version and replied to this one. Sorry, will re-read now. > > >> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h > >> index fc353b5..5de6ed3 100644 > >> --- a/include/uapi/linux/virtio_net.h > >> +++ b/include/uapi/linux/virtio_net.h > >> @@ -57,6 +57,8 @@ > >> * Steering */ > >> #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ > >> > >> +#define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */ > >> + > >> #ifndef VIRTIO_NET_NO_LEGACY > >> #define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */ > >> #endif /* VIRTIO_NET_NO_LEGACY */ > >> @@ -76,6 +78,17 @@ struct virtio_net_config { > >> __u16 max_virtqueue_pairs; > >> /* Default maximum transmit unit advice */ > >> __u16 mtu; > >> + /* > >> + * speed, in units of 1Mb. All values 0 to INT_MAX are legal. > >> + * Any other value stands for unknown. > >> + */ > >> + __u32 speed; > >> + /* > >> + * 0x00 - half duplex > >> + * 0x01 - full duplex > >> + * Any other value stands for unknown. > >> + */ > >> + __u8 duplex; > >> } __attribute__((packed)); > >> > >> /* > >> -- > >> 2.6.1