From: "Michael S. Tsirkin" <mst@redhat.com>
To: akong@redhat.com
Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org,
kvm@vger.kernel.org, virtualization@lists.linux-foundation.org
Subject: Re: [Qemu-devel] [RFC PATCH 2/2] virtio-net: introduce a new control to set macaddr
Date: Thu, 10 Jan 2013 17:26:50 +0200 [thread overview]
Message-ID: <20130110152649.GF30731@redhat.com> (raw)
In-Reply-To: <1357829141-25455-3-git-send-email-akong@redhat.com>
On Thu, Jan 10, 2013 at 10:45:41PM +0800, akong@redhat.com wrote:
> From: Amos Kong <akong@redhat.com>
>
> Currently we write MAC address to pci config space byte by byte,
> this means that we have an intermediate step where mac is wrong.
> This patch introduced a new control command to set MAC address
> in one time.
>
> VIRTIO_NET_F_CTRL_MAC_ADDR is a new feature bit for compatibility.
>
> Signed-off-by: Amos Kong <akong@redhat.com>
> ---
> drivers/net/virtio_net.c | 16 +++++++++++++++-
> include/uapi/linux/virtio_net.h | 8 +++++++-
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 395ab4f..ff22bcd 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -803,13 +803,26 @@ static int virtnet_set_mac_address(struct net_device *dev, void *p)
> struct virtio_device *vdev = vi->vdev;
> int ret;
>
> + struct scatterlist sg;
> +
> ret = eth_mac_addr(dev, p);
> if (ret)
> return ret;
>
> - if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC))
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR)) {
> + /* Set MAC address by sending vq command */
> + sg_init_one(&sg, dev->dev_addr, dev->addr_len);
> + virtnet_send_command(vi, VIRTIO_NET_CTRL_MAC,
> + VIRTIO_NET_CTRL_MAC_ADDR_SET,
> + &sg, 1, 0);
I think we should check status and return an error if the command failed.
Also, delay eth_mac_addr until after it passes.
> + return 0;
> + }
> +
> + if (virtio_has_feature(vdev, VIRTIO_NET_F_MAC)) {
> + /* Set MAC address by writing config space */
> vdev->config->set(vdev, offsetof(struct virtio_net_config, mac),
> dev->dev_addr, dev->addr_len);
> + }
>
By the way, why don't we fail the command if VIRTIO_NET_F_MAC is off?
Rusty?
> return 0;
> }
> @@ -1627,6 +1640,7 @@ static unsigned int features[] = {
> VIRTIO_NET_F_MRG_RXBUF, VIRTIO_NET_F_STATUS, VIRTIO_NET_F_CTRL_VQ,
> 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,
> };
>
> static struct virtio_driver virtio_net_driver = {
> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> index 848e358..a5a8c88 100644
> --- a/include/uapi/linux/virtio_net.h
> +++ b/include/uapi/linux/virtio_net.h
> @@ -53,6 +53,7 @@
> * network */
> #define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
> * Steering */
> +#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
>
> #define VIRTIO_NET_S_LINK_UP 1 /* Link is up */
> #define VIRTIO_NET_S_ANNOUNCE 2 /* Announcement is needed */
> @@ -127,7 +128,7 @@ typedef __u8 virtio_net_ctrl_ack;
> #define VIRTIO_NET_CTRL_RX_NOBCAST 5
>
> /*
> - * Control the MAC filter table.
> + * Control the MAC
> *
> * The MAC filter table is managed by the hypervisor, the guest should
> * assume the size is infinite. Filtering should be considered
> @@ -140,6 +141,10 @@ typedef __u8 virtio_net_ctrl_ack;
> * first sg list contains unicast addresses, the second is for multicast.
> * This functionality is present if the VIRTIO_NET_F_CTRL_RX feature
> * is available.
> + *
> + * The ADDR_SET command requests one out scatterlist, it contains a
> + * 6 bytes MAC address. This functionality is present if the
> + * VIRTIO_NET_F_CTRL_MAC_ADDR feature is available.
> */
> struct virtio_net_ctrl_mac {
> __u32 entries;
> @@ -148,6 +153,7 @@ struct virtio_net_ctrl_mac {
>
> #define VIRTIO_NET_CTRL_MAC 1
> #define VIRTIO_NET_CTRL_MAC_TABLE_SET 0
> + #define VIRTIO_NET_CTRL_MAC_ADDR_SET 1
>
> /*
> * Control VLAN filtering
> --
> 1.7.11.7
next prev parent reply other threads:[~2013-01-10 15:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-10 14:45 [Qemu-devel] [RFC PATCH 0/2] make mac programming for virtio net more robust akong
2013-01-10 14:45 ` [Qemu-devel] [RFC PATCH 1/2] move virtnet_send_command() above virtnet_set_mac_address() akong
2013-01-10 14:51 ` Jason Wang
2013-01-10 15:02 ` Michael S. Tsirkin
2013-01-10 14:45 ` [Qemu-devel] [RFC PATCH 2/2] virtio-net: introduce a new control to set macaddr akong
2013-01-10 14:57 ` Jason Wang
2013-01-16 5:23 ` Amos Kong
2013-01-16 9:17 ` Michael S. Tsirkin
2013-01-10 15:26 ` Michael S. Tsirkin [this message]
2013-01-11 0:43 ` Rusty Russell
2013-01-10 14:51 ` [Qemu-devel] [RFC PATCH] virtio-net: introduce a new macaddr control akong
2013-01-11 9:50 ` Stefan Hajnoczi
2013-01-10 15:08 ` [Qemu-devel] [RFC PATCH 0/2] make mac programming for virtio net more robust Amos Kong
2013-01-10 15:28 ` Michael S. Tsirkin
2013-01-11 2:23 ` Rusty Russell
2013-01-11 7:46 ` Michael S. Tsirkin
2013-01-11 14:52 ` John Fastabend
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130110152649.GF30731@redhat.com \
--to=mst@redhat.com \
--cc=akong@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).