incompatibility of netfront driver with bonding module

PATCH New Masroor Vettuparambil 2 participants 8 messages Mar 31, 2008 – Apr 10, 2008 Xen hypervisor interface

Share & tools

Masroor Vettuparambil

author

2008-03-31 15:40 UTC #0 lore raw

Hi all,

I am trying a live migration of pass-through enabled domU. The idea is configuring a bonding interface and enslave the pass-through NIC to it. During migration, enslave a vif and detach the NIC. But this is not working because of the incompatibility of netfront driver with bonding module.

1. Normally, bonding will inherit the mac from the first slave and assign it to all the other slaves added later. So the mac of vif will be updated. But during migration, the mac of vif is getting updated from xenstore(/vm/). So how about having a set_mac_address entry in netfront that update the xenstore?
2. arp link monitoring method relies on the slave driver's rx/tx timestamp. But in netfront, dev->last_rx and dev->trans_start are not being used, and fails to detect the link status.
3. In mii link monitoring, it relies on the netif_carrier_ok status. But as netfront is using itsown netfront_carrier_* functions, the status is not getting updated to bonding module.

So I need help, especially on #1. Is it ok to update the xenstore /vm/ keys from domU? how to do this?

thanks,
Masroor

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Yosuke Iwamatsu

2008-04-03 06:29 UTC #1 lore raw

Hi,

Quoted 3 lines · Masroor Vettuparambil

1. Normally, bonding will inherit the mac from the first slave and assign it to all the other slaves added later. So the mac of vif will be updated. But during migration, the mac of vif is getting updated from xenstore(/vm/). So how about having a set_mac_address entry in netfront that update the xenstore?
So I need help, especially on #1. Is it ok to update the xenstore /vm/ keys from domU? how to do this?

I tried a bit to find out the way to update /vm/ keys from frontend, but didn't succeed. Either way, I don't think it is a good idea to update the xenstore key of the vif mac address, because the original mac will be lost and we won't be able to reset it e.g. after the guest reboot.

So the attached patch adds set mac_address() support to netfront. It doesn't touch xenstore at all, but just preserves the modified mac address in netfront_info structure and keeps using it after migration.

Thanks,
-----------------------
Yosuke Iwamatsu
NEC Corporation

# HG changeset patch
# User [email protected]
# Date 1207201836 -32400
# Node ID e0cbf339041149119780900979653ac57a302e8a # Parent 06ffa3eb5e3ff1cf517c15b40a8cd757bc827950
netfront: Support set_mac_address()

Signed-off-by Yosuke Iwamatsu <[email protected]>

drivers/xen/netfront/netfront.c +23 -4

diff -r 06ffa3eb5e3f -r e0cbf3390411 drivers/xen/netfront/netfront.c
@@ -366,10 +366,14 @@ static int talk_to_backend(struct xenbus
 	struct xenbus_transaction xbt;
 	int err;
 
-	err = xen_net_read_mac(dev, info->mac);
-	if (err) {
-		xenbus_dev_fatal(dev, err, "parsing %s/mac", dev->nodename);
-		goto out;
+	/* Read mac only in the first setup. */
+	if (!is_valid_ether_addr(info->mac)) {
+		err = xen_net_read_mac(dev, info->mac);
+		if (err) {
+			xenbus_dev_fatal(dev, err, "parsing %s/mac",
+					 dev->nodename);
+			goto out;
+		}
 	}
 
 	/* Create shared ring, alloc event channel. */

@@ -1688,6 +1692,20 @@ static struct net_device_stats *network_
 	return &np->stats;
 }
 
+static int xennet_set_mac_address(struct net_device *dev, void *p)
+{
+	struct netfront_info *np = netdev_priv(dev);
+	struct sockaddr *addr = p;
+
+	if (!is_valid_ether_addr(addr->sa_data))
+		return -EADDRNOTAVAIL;
+	
+	memcpy(dev->dev_addr, addr->sa_data, dev->addr_len);
+	memcpy(np->mac, addr->sa_data, ETH_ALEN);
+
+	return 0;
+}
+
 static int xennet_change_mtu(struct net_device *dev, int mtu)
 {
 	int max = xennet_can_sg(dev) ? 65535 - ETH_HLEN : ETH_DATA_LEN;

@@ -2075,6 +2093,7 @@ static struct net_device * __devinit cre
 	netdev->poll            = netif_poll;
 	netdev->set_multicast_list = network_set_multicast_list;
 	netdev->uninit          = netif_uninit;
+	netdev->set_mac_address	= xennet_set_mac_address;
 	netdev->change_mtu	= xennet_change_mtu;
 	netdev->weight          = 64;
 	netdev->features        = NETIF_F_IP_CSUM;

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Masroor Vettuparambil

author

2008-04-04 10:25 UTC #2 lore raw

Thanks for your work.
I could manage the live migration using a simple check in netfront while resuming on destination.

if (!(netdev->flags & IFF_SLAVE))

	memcpy(netdev->dev_addr, info->mac, ETH_ALEN);

But this will work only if the interface is enslaved.

In your patch, should we let to change the MAC while interface is up? I need to include the support for arp link monitoring to netfront.

Regards
Masroor,

-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]]
Sent: Thursday, April 03, 2008 12:00 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module

Hi,

Quoted 9 lines · Masroor Vettuparambil

1. Normally, bonding will inherit the mac from the first slave and assign it to all the other slaves added later. So the mac of vif will be updated. But during migration, the mac of vif is getting updated from xenstore(/vm/). So how about having a set_mac_address entry in netfront that update the xenstore?
So I need help, especially on #1. Is it ok to update the xenstore /vm/
keys from domU? how to do this?

Thanks,
-----------------------
Yosuke Iwamatsu
NEC Corporation

Yosuke Iwamatsu

2008-04-07 07:05 UTC #3 lore raw

Quoted 9 lines · Masroor Vettuparambil

Thanks for your work.
I could manage the live migration using a simple check in netfront while resuming on destination.
if (!(netdev->flags & IFF_SLAVE))
	memcpy(netdev->dev_addr, info->mac, ETH_ALEN);
But this will work only if the interface is enslaved.
In your patch, should we let to change the MAC while interface is up?

It might be desirable, but I don't know for now if we can achieve it easily.

Quoted 1 line

I need to include the support for arp link monitoring to netfront.

Is link monitoring really necessary?
If you mean you use link monitoring to change the active slave of the bond0, I think we can do that using ifenslave command inside domU.
#ifenslave bond0 eth1 -> enslave new netif(eth1) to bonding device
#ifenslave -d bond0 eth0 -> release old netif(eth0) from bonding

Regards,
Yosuke

Quoted 33 lines

Regards
Masroor,
-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]] Sent: Thursday, April 03, 2008 12:00 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module
Hi,
Quoted 5 lines · Masroor Vettuparambil
1. Normally, bonding will inherit the mac from the first slave and assign it to all the other slaves added later. So the mac of vif will be updated. But during migration, the mac of vif is getting updated from xenstore(/vm/). So how about having a set_mac_address entry in netfront that update the xenstore?
So I need help, especially on #1. Is it ok to update the xenstore /vm/
keys from domU? how to do this?
I tried a bit to find out the way to update /vm/ keys from frontend, but didn't succeed. Either way, I don't think it is a good idea to update the xenstore key of the vif mac address, because the original mac will be lost and we won't be able to reset it e.g. after the guest reboot.
So the attached patch adds set mac_address() support to netfront. It doesn't touch xenstore at all, but just preserves the modified mac address in netfront_info structure and keeps using it after migration.
Thanks,
-----------------------
Yosuke Iwamatsu
NEC Corporation

Masroor Vettuparambil

author

2008-04-10 10:41 UTC #4 lore raw

The attached patch provides the arp link monitoring support for netfront.
Also it prevents setting the mac while the interface is up.

Regards
Masroor

-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]]
Sent: Monday, April 07, 2008 12:36 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module

Quoted 6 lines · Masroor Vettuparambil

Thanks for your work.
I could manage the live migration using a simple check in netfront while resuming on destination.
if (!(netdev->flags & IFF_SLAVE))
	memcpy(netdev->dev_addr, info->mac, ETH_ALEN); But this will

work

Quoted 3 lines

only if the interface is enslaved.
In your patch, should we let to change the MAC while interface is up?

It might be desirable, but I don't know for now if we can achieve it easily.

Quoted 1 line

I need to include the support for arp link monitoring to netfront.

Regards,
Yosuke

Quoted 25 lines

Regards
Masroor,
-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]]
Sent: Thursday, April 03, 2008 12:00 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module
Hi,
Quoted 9 lines · Masroor Vettuparambil
1. Normally, bonding will inherit the mac from the first slave and assign it to all the other slaves added later. So the mac of vif will
be updated. But during migration, the mac of vif is getting updated from xenstore(/vm/). So how about having a set_mac_address entry in netfront that update the xenstore?
So I need help, especially on #1. Is it ok to update the xenstore /vm/

Quoted 6 lines

Quoted 1 line
keys from domU? how to do this?
I tried a bit to find out the way to update /vm/ keys from frontend, but didn't succeed. Either way, I don't think it is a good idea to update the xenstore key of the vif mac address, because the original mac will be lost and we won't be able to reset it e.g. after the guest

reboot.

Quoted 9 lines

So the attached patch adds set mac_address() support to netfront. It doesn't touch xenstore at all, but just preserves the modified mac address in netfront_info structure and keeps using it after migration.
Thanks,
-----------------------
Yosuke Iwamatsu
NEC Corporation

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Yosuke Iwamatsu

2008-04-10 12:05 UTC #5 lore raw

Thank you.

Now I'm curious if you really succeeded the live migration of passthrough domains, using pci-hotplug and bonding. (Currently I have one testing machine and can only try local migration.)

-- Yosuke

Quoted 67 lines · Masroor Vettuparambil

The attached patch provides the arp link monitoring support for netfront.
Also it prevents setting the mac while the interface is up.
Regards
Masroor
-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]] Sent: Monday, April 07, 2008 12:36 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module
Quoted 5 lines · Masroor Vettuparambil
Thanks for your work.
I could manage the live migration using a simple check in netfront while resuming on destination.
if (!(netdev->flags & IFF_SLAVE))
	memcpy(netdev->dev_addr, info->mac, ETH_ALEN); But this will
work
Quoted 3 lines
only if the interface is enslaved.
In your patch, should we let to change the MAC while interface is up?
It might be desirable, but I don't know for now if we can achieve it easily.
Quoted 1 line
I need to include the support for arp link monitoring to netfront.
Is link monitoring really necessary?
If you mean you use link monitoring to change the active slave of the bond0, I think we can do that using ifenslave command inside domU.
#ifenslave bond0 eth1 -> enslave new netif(eth1) to bonding device
#ifenslave -d bond0 eth0 -> release old netif(eth0) from bonding
Regards,
Yosuke
Quoted 13 lines
Regards
Masroor,
-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]]
Sent: Thursday, April 03, 2008 12:00 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module
Hi,
Quoted 7 lines
Quoted 5 lines · Masroor Vettuparambil
1. Normally, bonding will inherit the mac from the first slave and assign it to all the other slaves added later. So the mac of vif will
be updated. But during migration, the mac of vif is getting updated from xenstore(/vm/). So how about having a set_mac_address entry in netfront that update the xenstore? So I need help, especially on #1. Is it ok to update the xenstore /vm/
keys from domU? how to do this?
I tried a bit to find out the way to update /vm/ keys from frontend, but didn't succeed. Either way, I don't think it is a good idea to update the xenstore key of the vif mac address, because the original mac will be lost and we won't be able to reset it e.g. after the guest
reboot.
Quoted 7 lines
So the attached patch adds set mac_address() support to netfront.
It doesn't touch xenstore at all, but just preserves the modified mac address in netfront_info structure and keeps using it after migration.
Thanks,
-----------------------
Yosuke Iwamatsu
NEC Corporation

Masroor Vettuparambil

author

2008-04-10 12:24 UTC #6 lore raw

Yes, I could do a live migration of pass-through domain using bonding.

Regards
Masroor

-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]]
Sent: Thursday, April 10, 2008 5:35 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: Re: [PATCH] incompatibility of netfront driver with bonding module

Thank you.

Now I'm curious if you really succeeded the live migration of passthrough domains, using pci-hotplug and bonding. (Currently I have one testing machine and can only try local migration.)

-- Yosuke

Quoted 29 lines · Masroor Vettuparambil

The attached patch provides the arp link monitoring support for netfront.
Also it prevents setting the mac while the interface is up.
Regards
Masroor
-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]]
Sent: Monday, April 07, 2008 12:36 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module
Quoted 6 lines · Masroor Vettuparambil
Thanks for your work.
I could manage the live migration using a simple check in netfront while resuming on destination.
if (!(netdev->flags & IFF_SLAVE))
	memcpy(netdev->dev_addr, info->mac, ETH_ALEN); But this will
work
Quoted 3 lines
only if the interface is enslaved.
In your patch, should we let to change the MAC while interface is up?
It might be desirable, but I don't know for now if we can achieve it easily.

Quoted 6 lines

Quoted 1 line
I need to include the support for arp link monitoring to netfront.
Is link monitoring really necessary?
If you mean you use link monitoring to change the active slave of the bond0, I think we can do that using ifenslave command inside domU.
#ifenslave bond0 eth1 -> enslave new netif(eth1) to bonding

device

Quoted 28 lines

  #ifenslave -d bond0 eth0  -> release old netif(eth0) from bonding
Regards,
Yosuke
Quoted 23 lines
Regards
Masroor,
-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]]
Sent: Thursday, April 03, 2008 12:00 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module
Hi,
Quoted 9 lines · Masroor Vettuparambil
1. Normally, bonding will inherit the mac from the first slave and assign it to all the other slaves added later. So the mac of vif will
be updated. But during migration, the mac of vif is getting updated from xenstore(/vm/). So how about having a set_mac_address entry in netfront that update the xenstore?
So I need help, especially on #1. Is it ok to update the xenstore /vm/ keys from domU? how to do this?

Quoted 10 lines

Quoted 5 lines
I tried a bit to find out the way to update /vm/ keys from frontend, but didn't succeed. Either way, I don't think it is a good idea to update the xenstore key of the vif mac address, because the original mac will be lost and we won't be able to reset it e.g. after the guest
reboot.
Quoted 4 lines
So the attached patch adds set mac_address() support to netfront. It doesn't touch xenstore at all, but just preserves the modified mac
address in netfront_info structure and keeps using it after

migration.

Quoted 6 lines

Quoted 5 lines
Thanks,
-----------------------
Yosuke Iwamatsu
NEC Corporation

Yosuke Iwamatsu

2008-04-10 12:30 UTC #7 lore raw

PATCH 1/1 incompatibility of netfront driver with bonding module

Quoted 1 line · Masroor Vettuparambil

Yes, I could do a live migration of pass-through domain using bonding.

That's great!

Thanks,
Yosuke

Quoted 79 lines

-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]] Sent: Thursday, April 10, 2008 5:35 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: Re: [PATCH] incompatibility of netfront driver with bonding
module
Thank you.
Now I'm curious if you really succeeded the live migration of passthrough domains, using pci-hotplug and bonding. (Currently I have one testing machine and can only try local migration.)
-- Yosuke
Quoted 22 lines · Masroor Vettuparambil
The attached patch provides the arp link monitoring support for netfront. Also it prevents setting the mac while the interface is up.
Regards
Masroor
-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]]
Sent: Monday, April 07, 2008 12:36 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module
Quoted 5 lines · Masroor Vettuparambil
Thanks for your work.
I could manage the live migration using a simple check in netfront while resuming on destination.
if (!(netdev->flags & IFF_SLAVE))
	memcpy(netdev->dev_addr, info->mac, ETH_ALEN); But this will
work
Quoted 2 lines
only if the interface is enslaved.
Quoted 7 lines
Quoted 1 line
In your patch, should we let to change the MAC while interface is up?
It might be desirable, but I don't know for now if we can achieve it easily.
Quoted 1 line
I need to include the support for arp link monitoring to netfront.
Is link monitoring really necessary?
If you mean you use link monitoring to change the active slave of the bond0, I think we can do that using ifenslave command inside domU.
#ifenslave bond0 eth1 -> enslave new netif(eth1) to bonding
device
Quoted 16 lines
  #ifenslave -d bond0 eth0  -> release old netif(eth0) from bonding
Regards,
Yosuke
Quoted 11 lines
Regards
Masroor,
-----Original Message-----
From: Yosuke Iwamatsu [mailto:[email protected]]
Sent: Thursday, April 03, 2008 12:00 PM
To: Masroor Vettuparambil
Cc: [email protected]
Subject: incompatibility of netfront driver with bonding module
Quoted 12 lines
Quoted 7 lines
Hi,
Quoted 3 lines · Masroor Vettuparambil
1. Normally, bonding will inherit the mac from the first slave and assign it to all the other slaves added later. So the mac of vif will
be updated. But during migration, the mac of vif is getting updated from xenstore(/vm/). So how about having a set_mac_address entry in netfront that update the xenstore? So I need help, especially on #1. Is it ok to update the xenstore /vm/ keys from domU? how to do this?
I tried a bit to find out the way to update /vm/ keys from frontend, but didn't succeed. Either way, I don't think it is a good idea to update the xenstore key of the vif mac address, because the original mac will be lost and we won't be able to reset it e.g. after the guest
reboot.
Quoted 4 lines
So the attached patch adds set mac_address() support to netfront. It doesn't touch xenstore at all, but just preserves the modified mac
address in netfront_info structure and keeps using it after
migration.
Quoted 4 lines
Quoted 4 lines
Thanks,
-----------------------
Yosuke Iwamatsu
NEC Corporation