xn0: Error 2 parsing device/vif/0/mac [PATCH]

[Justin T. Gibbs]

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