From owner-freebsd-xen@FreeBSD.ORG Tue Feb 1 00:18:30 2011 Return-Path: Delivered-To: freebsd-xen@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89E431065675 for ; Tue, 1 Feb 2011 00:18:30 +0000 (UTC) (envelope-from gibbs@FreeBSD.org) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0BE8FC1D for ; Tue, 1 Feb 2011 00:18:30 +0000 (UTC) Received: from [192.168.4.138] (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.4/8.14.4) with ESMTP id p110IOPS075740 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Jan 2011 17:18:25 -0700 (MST) (envelope-from gibbs@FreeBSD.org) Message-ID: <4D47514C.7090706@FreeBSD.org> Date: Mon, 31 Jan 2011 17:18:20 -0700 From: "Justin T. Gibbs" Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.14) Gecko/20110123 Thunderbird/3.1.8 MIME-Version: 1.0 To: Janne Snabb References: In-Reply-To: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (aslan.scsiguy.com [70.89.174.89]); Mon, 31 Jan 2011 17:18:25 -0700 (MST) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-xen@FreeBSD.org Subject: Re: xn0: Error 2 parsing device/vif/0/mac [PATCH] X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gibbs@FreeBSD.org List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 00:18:30 -0000 On 1/15/2011 3:12 AM, Janne Snabb wrote: > On Sat, 15 Jan 2011, Janne Snabb wrote: > >> It appears that that the netfront driver fails to get the vif mac >> address which leads to panic shortly afterwards. > > The patch at the bottom of this message solves the problem for me. > After that the current 8.2RC2 system works fine on amd64 with XENHVM > kernel with Xen 4.0.1 (have not tested other versions). > > If the "mac" node does not appear in the front-end vif directory > (does it ever appear there? in my experience no), we fetch a link > to the backend directory for the same vif and try to get the "mac" > node from there. > > I am not sure if this is the proper way to fix this, but it works > for me. As with most things Xen, there is no official specification for what xenstore nodes are where. If we assume the Linux driver is the definitive reference, then the current FreeBSD driver behavior is correct: http://xenbits.xensource.com/linux-2.6.18-xen.hg?file/5e08fff8dc05/drivers/xen/netfront/netfront.c See talk_to_backend() and the xen_net_read_mac() function. There are two environments that setup the xenstore nodes: the Xen cloud platform, and the more common phython tool stack (aka xend). I haven't reviewed XCP, but Xend populates the MAC node in the frontend's tree unless the "ioemu" tag is in the VIF configuration line for that interface. Why this is the case, I have no idea - again the behavior is not documented. However, it seems reasonable to do what you've done in this patch and to rely on the backend's copy if the frontend's doesn't exist. It would also be good to add support to netfront to maintain the mac node in the frontend tree and to allow it to be set just like a real device. I believe netback will pick up and use the updated MAC value if you bounce the Xenbus connection after making the change. -- Justin