This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH] xen-netfront: delay gARP until backend switches to C

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [PATCH] xen-netfront: delay gARP until backend switches to Connected
From: Laszlo Ersek <lersek@xxxxxxxxxx>
Date: Mon, 11 Jul 2011 16:22:24 +0200
Delivery-date: Mon, 11 Jul 2011 07:21:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1309268019.32717.322.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1309268019.32717.322.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 06/28/11 15:33, Ian Campbell wrote:

> netback already waits (or should...) for hotplug-status to fire with
> "connected" before moving to state XenbusStateConnected. See
> hotplug_status_changed in drivers/net/xen-netback/xenbus.c. You need
> either the netback in upstream or something newer than 43223efd9bfd (C
> Feb 2010) if you are using e.g. xen.git#xen/next-2.6.32. That commit
> fixes pretty much the issue you describe.
> I expected that netfront waited for the backend to hit
> XenbusStateConnected before sending the grat ARP but instead I find it
> happens when the backend hits XenbusStateInitWait. I'm not sure if that
> is a problem -- it appears to have been done this way since forever
> (even back in the classic Xen kernels) and I've never noticed a gARP go
> missing in the way you describe, but perhaps something isn't quite
> matching up any more.

In addition to backporting 43223efd9bfd to the RHEL-5 host side, we needed the
following in the RHEL-6 guest, in order to fix the network outage after live
migration. The patch is for xen/next-2.6.32. I also tested a Fedora-15 guest
(without the patch), and the backport to the host side alone was not sufficient
there either.

Thanks for the help and for considering this one.

Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
 drivers/net/xen-netfront.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3f71199..214c3a4 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1732,7 +1732,6 @@ static void netback_changed(struct xenbus_device *dev,
        case XenbusStateInitialised:
        case XenbusStateReconfiguring:
        case XenbusStateReconfigured:
-       case XenbusStateConnected:
        case XenbusStateUnknown:
        case XenbusStateClosed:
@@ -1743,6 +1742,9 @@ static void netback_changed(struct xenbus_device *dev,
                if (xennet_connect(netdev) != 0)
                xenbus_switch_state(dev, XenbusStateConnected);
+               break;
+       case XenbusStateConnected:

Xen-devel mailing list