From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:37363)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <akong@redhat.com>) id 1TvLT8-000071-2u
	for qemu-devel@nongnu.org; Wed, 16 Jan 2013 00:23:23 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <akong@redhat.com>) id 1TvLT7-0004il-25
	for qemu-devel@nongnu.org; Wed, 16 Jan 2013 00:23:22 -0500
Received: from mx1.redhat.com ([209.132.183.28]:55155)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <akong@redhat.com>) id 1TvLT6-0004iU-Qy
	for qemu-devel@nongnu.org; Wed, 16 Jan 2013 00:23:20 -0500
Date: Wed, 16 Jan 2013 13:23:26 +0800
From: Amos Kong <akong@redhat.com>
Message-ID: <20130116052326.GA4279@t430s.nay.redhat.com>
References: <1357829141-25455-1-git-send-email-akong@redhat.com>
	<1357829141-25455-3-git-send-email-akong@redhat.com>
	<50EED6C1.1040608@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50EED6C1.1040608@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH 2/2] virtio-net: introduce a new
 control to set macaddr
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jason Wang <jasowang@redhat.com>
Cc: rusty@rustcorp.com.au, mst@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org

On Thu, Jan 10, 2013 at 10:57:05PM +0800, Jason Wang wrote:
> On 01/10/2013 10:45 PM, 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);
> > +		return 0;
> > +	}
> > +
> 
> Better to check the return of virtnet_send_command() and give a warn
> like other command. Btw, need we fail back to try the old way then?

Yes, it's necessary to check the return value of
virtnet_send_command().

In fail case, I like to return -EINVAL to userspace, because we don't
only want to set mac successfully, we also want to resolve the
addr inconsistent issue by this feature (vq cmd).