From snabb@tiktik.epipe.com  Wed Jan 26 08:59:17 2011
Return-Path: <snabb@tiktik.epipe.com>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 41A7D1065694
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 26 Jan 2011 08:59:17 +0000 (UTC)
	(envelope-from snabb@tiktik.epipe.com)
Received: from tiktik.epipe.com (tiktik.epipe.com [IPv6:2001:1828:0:3::2])
	by mx1.freebsd.org (Postfix) with ESMTP id C5F9C8FC08
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 26 Jan 2011 08:59:16 +0000 (UTC)
Received: from tiktik.epipe.com (localhost [127.0.0.1])
	by tiktik.epipe.com (8.14.4/8.14.4) with ESMTP id p0Q8xCcY024512
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 26 Jan 2011 08:59:15 GMT
	(envelope-from snabb@tiktik.epipe.com)
Received: (from snabb@localhost)
	by tiktik.epipe.com (8.14.4/8.14.4/Submit) id p0Q8xCpk024330;
	Wed, 26 Jan 2011 08:59:12 GMT
	(envelope-from snabb)
Message-Id: <201101260859.p0Q8xCpk024330@tiktik.epipe.com>
Date: Wed, 26 Jan 2011 08:59:12 GMT
From: Janne Snabb <snabb@epipe.com>
Reply-To: Janne Snabb <snabb@epipe.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc: snabb@epipe.com
Subject: [xen] [panic] [patch] xn0: Error 2 parsing device/vif/0/mac
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         154302
>Category:       kern
>Synopsis:       [xen] [panic] [patch] xn0: Error 2 parsing device/vif/0/mac
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-xen
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 26 09:00:23 UTC 2011
>Closed-Date:    Tue Sep 27 13:41:12 UTC 2011
>Last-Modified:  Tue Jan 31 18:20:12 UTC 2012
>Originator:     Janne Snabb <snabb@epipe.com>
>Release:        FreeBSD 8.2-RC2 amd64
>Organization:
EPIPE Communications
>Environment:
8.2RC1 (i386 and amd64) as distributed and 8.2RC2 (amd64) as of
2011-01-14 as well as CURRENT (amd64) as of 2011-01-14 (r217387).

Xen 4.0.1 with Gentoo (x86_64 testing) dom0 and also Xen 4.0.1,
3.4.3 and 3.3.2 with CentOS 5.5 (x86_64) dom0. Various Linux dom0
kernel versions.

>Description:
I have been trying to get Xen para-virtualized device drivers to
work with RELENG_8_2 and -current. It appears that that the netfront
driver fails to get the vif mac address which leads to panic shortly
afterwards. The Xen networking mode is bridged (with default config,
automatically allocated mac address). Setting the mac address manually
in Xen config does not help.

If I enable the xenbus drivers (XENHVM kernel config on amd64 or
XEN on i386) I always get the following result:

[..]
xenpci0: <Xen Platform Device> port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff
irq 28 at device 3.0 on pci0
xs_probe: Probe retuns 0
xenstore0: <XenStore> on xenpci0
[..]
xenbusb_front0: <Xen Frontend Devices> on xenstore0
xn0: <Virtual Network Interface> at device/vif/0 on xenbusb_front0
xn0: Error 2 parsing device/vif/0/mac
xn0: Fatal error. Transitioning to Closing State
xbd0: 30720MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
xbd0: attaching as ad0
xbd1: 332MB <Virtual Block Device> at device/vbd/5632 on xenbusb_front0
xbd1: attaching as ad2
panic: do something smart

When using full HVM mode (emulated realtek) I have no problems with
Xen 4.0.1 nor 3.4.3 (both i386 and amd64 GENERIC kernels work fine).

There is a mailing list thread by myself about this at:

http://lists.freebsd.org/pipermail/freebsd-xen/2011-January/000761.html

...where one other person also confirms this problem at:

http://lists.freebsd.org/pipermail/freebsd-xen/2011-January/000775.html

He also confirms that my patch fixes the problem for him.

Below is one full boot message log with a kernel backtrace. RELENG_8_2
kernel amd64 config XENHVM (Xen 4.0.1 HVM mode):

KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2011 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.2-RC2 #2: Fri Jan 14 06:05:39 UTC 2011
    snabb@xxx.epipe.com:/usr/obj/usr/src/sys/XENHVM amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU           X3460  @ 2.80GHz (2800.02-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x106e5  Family = 6  Model = 1e  Stepping = 5
  Features=0x1781fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x80982201<SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,<b31>>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  TSC: P-state invariant
real memory  = 1073741824 (1024 MB)
avail memory = 1016918016 (969 MB)
ACPI APIC Table: <Xen HVM>
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 8 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  2
 cpu2 (AP): APIC ID:  4
 cpu3 (AP): APIC ID:  6
 cpu4 (AP): APIC ID:  8
 cpu5 (AP): APIC ID: 10
 cpu6 (AP): APIC ID: 12
 cpu7 (AP): APIC ID: 14
ioapic0: Changing APIC ID to 1
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 1.1> irqs 0-47 on motherboard
kbd1 at kbdmux0
acpi0: <Xen> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
acpi0: Sleep Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1f48-0x1f4b on acpi0
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
cpu4: <ACPI CPU> on acpi0
cpu5: <ACPI CPU> on acpi0
cpu6: <ACPI CPU> on acpi0
cpu7: <ACPI CPU> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
isab0: <PCI-ISA bridge> at device 1.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel PIIX3 WDMA2 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc200-0xc20f at device 1.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pci0: <bridge> at device 1.3 (no driver attached)
vgapci0: <VGA-compatible display> mem 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0
xenpci0: <Xen Platform Device> port 0xc000-0xc0ff mem 0xf2000000-0xf2ffffff irq 28 at device 3.0 on pci0
xs_probe: Probe retuns 0
xenstore0: <XenStore> on xenpci0
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse Explorer, device ID 4
fdc0: <floppy drive controller> port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: does not respond
device_attach: fdc0 attach returned 6
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
uart0: console (9600,n,8,1)
ppc0: <Parallel port> port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppc0: [ITHREAD]
ppbus0: <Parallel port bus> on ppc0
plip0: <PLIP network interface> on ppbus0
plip0: [ITHREAD]
lpt0: <Printer> on ppbus0
lpt0: [ITHREAD]
lpt0: Interrupt-driven port
ppi0: <Parallel I/O> on ppbus0
orm0: <ISA Option ROM> at iomem 0xc9000-0xc97ff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x100>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Timecounters tick every 10.000 msec
acd0: CDROM <QEMU DVD-ROM/0.10.2> at ata1-master WDMA2 
xenbusb_front0: <Xen Frontend Devices> on xenstore0
xn0: <Virtual Network Interface> at device/vif/0 on xenbusb_front0
xn0: Error 2 parsing device/vif/0/mac
xn0: Fatal error. Transitioning to Closing State
xbd0: 30720MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
xbd0: attaching as ad0
xbd1: 332MB <Virtual Block Device> at device/vbd/5632 on xenbusb_front0
xbd1: attaching as ad2
panic: do something smart
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
panic() at panic+0x187
netfront_attach() at netfront_attach+0x18c
device_attach() at device_attach+0x69
xenbusb_probe_children() at xenbusb_probe_children+0xdf
xenbusb_attach() at xenbusb_attach+0x11c
device_attach() at device_attach+0x69
bus_generic_attach() at bus_generic_attach+0x1a
xs_attach_deferred() at xs_attach_deferred+0x21
run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0xab
boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x2c
mi_startup() at mi_startup+0x77
btext() at btext+0x2c
KDB: enter: panic
[thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x3d: movq    $0,0x6c7a90(%rip)
db> halt

>How-To-Repeat:

Try to boot i386 XEN kernel or amd64 XENHVM kernel in similar
environment. Obviously this does not happen with every Xen environment
as there is no prior reports about this.

>Fix:

If the "mac" node does not appear in the front-end vif directory,
look for it in the backend directory for the same vif.

Two alternative patches:

--- sys/dev/xen/netfront/netfront.c.orig	2010-12-21 17:09:25.000000000 +0000
+++ sys/dev/xen/netfront/netfront.c	2011-01-17 10:11:06.000000000 +0000
@@ -401,13 +401,14 @@
 xen_net_read_mac(device_t dev, uint8_t mac[])
 {
 	int error, i;
 	char *s, *e, *macstr;
 
-	error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL,
-	    (void **) &macstr);
-	if (error)
+	if (xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL,
+	    (void **) &macstr) == ENOENT &&
+	    (error = xs_read(XST_NIL, xenbus_get_otherend_path(dev), 
+	    "mac", NULL, (void **) &macstr)) != 0)
 		return (error);
 
 	s = macstr;
 	for (i = 0; i < ETHER_ADDR_LEN; i++) {
 		mac[i] = strtoul(s, &e, 16);



--- sys/dev/xen/netfront/netfront.c.orig	2010-12-21 17:09:25.000000000 +0000
+++ sys/dev/xen/netfront/netfront.c	2011-01-17 10:11:06.000000000 +0000
@@ -401,13 +401,14 @@
 xen_net_read_mac(device_t dev, uint8_t mac[])
 {
 	int error, i;
 	char *s, *e, *macstr;
 
-	error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL,
-	    (void **) &macstr);
-	if (error)
+	if ((error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL,
+	    (void **) &macstr)) != 0 &&
+	    (error = xs_read(XST_NIL, xenbus_get_otherend_path(dev), 
+	    "mac", NULL, (void **) &macstr)) != 0)
 		return (error);
 
 	s = macstr;
 	for (i = 0; i < ETHER_ADDR_LEN; i++) {
 		mac[i] = strtoul(s, &e, 16);
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-xen 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Jan 26 11:00:00 UTC 2011 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=154302 

From: Janne Snabb <snabb@epipe.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/154302: First patch is not good
Date: Fri, 28 Jan 2011 07:26:05 +0000 (UTC)

 I wanted to add that the 1st patch I provided is not a good idea.
 
 It does not take into account that some other error than ENOENT
 could be returned.
 
 The 2nd patch is better.
 
 Alternatively it could be split to 2 separate if clauses.
 
 --
 Janne Snabb / EPIPE Communications
 snabb@epipe.com - http://epipe.com/

From: Janne Snabb <snabb@epipe.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/154302: xn0: Error 2 parsing device/vif/0/mac
 [WORKAROUND]
Date: Sat, 12 Feb 2011 09:12:06 +0000 (UTC)

 Justin T. Gibbs pointed out[1] that there is a simple workaround
 to this problem:
 
 Just remove 'type=ioemu' from the Xen domU's configuration.
 
 For example change:
 
 vif = [ 'type=ioemu, bridge=br0' ]
 
 ...to:
 
 vif = [ 'bridge=br0' ]
 
 After that the the mac node magically appears on the front-end side:
 
 # xenstore-read device/vif/0/mac
 00:16:3e:69:3e:99
 
 I think there is still a need for a patch though because not everyone
 (for examle VPS customers) have access to their domU's configuration.
 
 
 References:
 
 [1] http://lists.freebsd.org/pipermail/freebsd-xen/2011-February/000825.html
 
 --
 Janne Snabb / EPIPE Communications
 snabb@epipe.com - http://epipe.com/

From: Nick Sayer <nsayer@kfu.com>
To: bug-followup@FreeBSD.org, snabb@epipe.com
Cc:  
Subject: Re: kern/154302: [xen] [panic] [patch] xn0: Error 2 parsing device/vif/0/mac
Date: Sun, 13 Feb 2011 00:36:31 -0800

 > I think there is still a need for a patch though because not everyone
 > (for examle VPS customers) have access to their domU's configuration.
 
 Seconded. I am in this boat, and the patch is necessary and effective.

From: Alex <joovke@joovke.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/154302: [xen] [panic] [patch] xn0: Error 2 parsing device/vif/0/mac
Date: Mon, 14 Feb 2011 23:15:25 +1100

 Thirded. My Xen VPS is unusable without this patch (unless I revert back 
 to a non XEN kernel like GENERIC).
 
 

From: Janne Snabb <snabb@epipe.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/154302: Linux suffers from the same problem
Date: Tue, 5 Apr 2011 08:47:26 +0000 (UTC)

 Just an interesting note about this issue:
 
 I noticed that Linux suffers from the same problem. The Linux driver
 is somehow able to proceed even though getting the mac address
 fails. Therefore this Xen bug/feature does not cause headaches
 there, even though we need a workaround in FreeBSD driver.
 
 Have a look at Red Hat's virtualization guide:
 
 http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/sect-Virtualization-Troubleshooting_the_Xen_para_virtualized_drivers-Verifying_the_para_virtualized_drivers_have_successfully_loaded.html
 
 There you will see the following line:
 
 vif vif-0: 2 parsing device/vif/0/mac
 
 ...which is an indication of this very same error condition. 
 
 However according to the Red Hat documentation this just means that
 the PV drivers have successfully loaded :).
 
 --
 Janne Snabb / EPIPE Communications
 snabb@epipe.com - http://epipe.com/

From: Janne Snabb <snabb@epipe.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/154302: better do-something-smart.patch
Date: Sun, 22 May 2011 09:16:19 +0000 (UTC)

 Here is a new patch which is hopefully neat enough to be committed. 
 
 Could someone with a commit bit consider this? Lots of people are
 having trouble beacuse of this bug. It can be argued that the bug
 is in Xen and not in FreeBSD, but in reality we do need a work-around
 in FreeBSD. (Or if not, the panic message should be "something
 smarter". :)
 
 --- do-something-smart.patch begins here ---
 Index: sys/dev/xen/netfront/netfront.c
 ===================================================================
 --- sys/dev/xen/netfront/netfront.c	(revision 222131)
 +++ sys/dev/xen/netfront/netfront.c	(working copy)
 @@ -408,9 +408,27 @@
  
  	error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL,
  	    (void **) &macstr);
 -	if (error)
 -		return (error);
  
 +	if (error) {
 +		/*
 +		 * Try to read the 'mac' node from the backend side in case
 +		 * it does not exist (ENOENT) in the frontend side. This
 +		 * happens with various Xen versions if 'type=ioemu' is set
 +		 * in the vif configuration. See PR 154302 for more details.
 +		 * Otherwise return the error to the caller.
 +		 */
 +		if (error != ENOENT)
 +			return (error);
 +
 +		if (xs_read(XST_NIL, xenbus_get_otherend_path(dev), "mac",
 +		    NULL, (void **) &macstr) != 0)
 +			/*
 +			 * Return the error code of the frontend read (it
 +			 * is always ENOENT at this point).
 +			 */
 +			return (error);
 +	}
 +
  	s = macstr;
  	for (i = 0; i < ETHER_ADDR_LEN; i++) {
  		mac[i] = strtoul(s, &e, 16);
 --- do-something-smart.patch ends here ---
 
 --
 Janne Snabb / EPIPE Communications
 snabb@epipe.com - http://epipe.com/

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/154302: commit references a PR
Date: Wed, 21 Sep 2011 00:13:12 +0000 (UTC)

 Author: gibbs
 Date: Wed Sep 21 00:13:04 2011
 New Revision: 225708
 URL: http://svn.freebsd.org/changeset/base/225708
 
 Log:
   Modify the netfront driver so it can successfully attach to
   PV devices with the ioemu attribute set.
   
   sys/dev/xen/netfront/netfront.c:
   	o If a mac address for the interface cannot be found
   	  in the front-side XenStore tree, look for an entry
   	  in the back-side tree.  With ioemu devices, the
   	  emulator does not populate the front side tree and
   	  neither does Xend.
   	o Return an error rather than panic when an attach
   	  attempt fails.
   
   Reported by:	Janne Snabb (fix inspired by patch provided)
   PR:		kern/154302
   Approved by:	re
 
 Modified:
   head/sys/dev/xen/netfront/netfront.c
 
 Modified: head/sys/dev/xen/netfront/netfront.c
 ==============================================================================
 --- head/sys/dev/xen/netfront/netfront.c	Wed Sep 21 00:08:25 2011	(r225707)
 +++ head/sys/dev/xen/netfront/netfront.c	Wed Sep 21 00:13:04 2011	(r225708)
 @@ -406,11 +406,33 @@ xen_net_read_mac(device_t dev, uint8_t m
  {
  	int error, i;
  	char *s, *e, *macstr;
 +	const char *path;
  
 -	error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL,
 -	    (void **) &macstr);
 -	if (error)
 +	path = xenbus_get_node(dev);
 +	error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr);
 +	if (error == ENOENT) {
 +		/*
 +		 * Deal with missing mac XenStore nodes on devices with
 +		 * HVM emulation (the 'ioemu' configuration attribute)
 +		 * enabled.
 +		 *
 +		 * The HVM emulator may execute in a stub device model
 +		 * domain which lacks the permission, only given to Dom0,
 +		 * to update the guest's XenStore tree.  For this reason,
 +		 * the HVM emulator doesn't even attempt to write the
 +		 * front-side mac node, even when operating in Dom0.
 +		 * However, there should always be a mac listed in the
 +		 * backend tree.  Fallback to this version if our query
 +		 * of the front side XenStore location doesn't find
 +		 * anything.
 +		 */
 +		path = xenbus_get_otherend_path(dev);
 +		error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr);
 +	}
 +	if (error != 0) {
 +		xenbus_dev_fatal(dev, error, "parsing %s/mac", path);
  		return (error);
 +	}
  
  	s = macstr;
  	for (i = 0; i < ETHER_ADDR_LEN; i++) {
 @@ -451,7 +473,7 @@ netfront_attach(device_t dev)
  	err = create_netdev(dev);
  	if (err) {
  		xenbus_dev_fatal(dev, err, "creating netdev");
 -		return err;
 +		return (err);
  	}
  
  #if __FreeBSD_version >= 700000
 @@ -461,7 +483,7 @@ netfront_attach(device_t dev)
  	    &xn_enable_lro, 0, "Large Receive Offload");
  #endif
  
 -	return 0;
 +	return (0);
  }
  
  static int
 @@ -2067,11 +2089,8 @@ create_netdev(device_t dev)
  	}
  	
  	err = xen_net_read_mac(dev, np->mac);
 -	if (err) {
 -		xenbus_dev_fatal(dev, err, "parsing %s/mac",
 -		    xenbus_get_node(dev));
 +	if (err)
  		goto out;
 -	}
  	
  	/* Set up ifnet structure */
  	ifp = np->xn_ifp = if_alloc(IFT_ETHER);
 @@ -2105,8 +2124,7 @@ create_netdev(device_t dev)
  exit:
  	gnttab_free_grant_references(np->gref_tx_head);
  out:
 -	panic("do something smart");
 -
 +	return (err);
  }
  
  /**
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->closed 
State-Changed-By: gibbs 
State-Changed-When: Tue Sep 27 13:40:19 UTC 2011 
State-Changed-Why:  


http://www.freebsd.org/cgi/query-pr.cgi?pr=154302 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/154302: commit references a PR
Date: Tue, 31 Jan 2012 18:13:59 +0000 (UTC)

 Author: gibbs
 Date: Tue Jan 31 18:13:49 2012
 New Revision: 230831
 URL: http://svn.freebsd.org/changeset/base/230831
 
 Log:
   MFC r225708 into stable/8:
   
   Modify the netfront driver so it can successfully attach to
   PV devices with the ioemu attribute set.
   
   sys/dev/xen/netfront/netfront.c:
   	o If a mac address for the interface cannot be found
   	  in the front-side XenStore tree, look for an entry
   	  in the back-side tree.  With ioemu devices, the
   	  emulator does not populate the front side tree and
   	  neither does Xend.
   	o Return an error rather than panic when an attach
   	  attempt fails.
   
   Reported by:	Janne Snabb (fix inspired by patch provided)
   PR:		kern/154302
 
 Modified:
   stable/8/sys/dev/xen/netfront/netfront.c
 Directory Properties:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
 
 Modified: stable/8/sys/dev/xen/netfront/netfront.c
 ==============================================================================
 --- stable/8/sys/dev/xen/netfront/netfront.c	Tue Jan 31 17:51:30 2012	(r230830)
 +++ stable/8/sys/dev/xen/netfront/netfront.c	Tue Jan 31 18:13:49 2012	(r230831)
 @@ -402,11 +402,33 @@ xen_net_read_mac(device_t dev, uint8_t m
  {
  	int error, i;
  	char *s, *e, *macstr;
 +	const char *path;
  
 -	error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL,
 -	    (void **) &macstr);
 -	if (error)
 +	path = xenbus_get_node(dev);
 +	error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr);
 +	if (error == ENOENT) {
 +		/*
 +		 * Deal with missing mac XenStore nodes on devices with
 +		 * HVM emulation (the 'ioemu' configuration attribute)
 +		 * enabled.
 +		 *
 +		 * The HVM emulator may execute in a stub device model
 +		 * domain which lacks the permission, only given to Dom0,
 +		 * to update the guest's XenStore tree.  For this reason,
 +		 * the HVM emulator doesn't even attempt to write the
 +		 * front-side mac node, even when operating in Dom0.
 +		 * However, there should always be a mac listed in the
 +		 * backend tree.  Fallback to this version if our query
 +		 * of the front side XenStore location doesn't find
 +		 * anything.
 +		 */
 +		path = xenbus_get_otherend_path(dev);
 +		error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr);
 +	}
 +	if (error != 0) {
 +		xenbus_dev_fatal(dev, error, "parsing %s/mac", path);
  		return (error);
 +	}
  
  	s = macstr;
  	for (i = 0; i < ETHER_ADDR_LEN; i++) {
 @@ -447,7 +469,7 @@ netfront_attach(device_t dev)
  	err = create_netdev(dev);
  	if (err) {
  		xenbus_dev_fatal(dev, err, "creating netdev");
 -		return err;
 +		return (err);
  	}
  
  #if __FreeBSD_version >= 700000
 @@ -457,7 +479,7 @@ netfront_attach(device_t dev)
  	    &xn_enable_lro, 0, "Large Receive Offload");
  #endif
  
 -	return 0;
 +	return (0);
  }
  
  
 @@ -2020,11 +2042,8 @@ create_netdev(device_t dev)
  	}
  	
  	err = xen_net_read_mac(dev, np->mac);
 -	if (err) {
 -		xenbus_dev_fatal(dev, err, "parsing %s/mac",
 -		    xenbus_get_node(dev));
 +	if (err)
  		goto out;
 -	}
  	
  	/* Set up ifnet structure */
  	ifp = np->xn_ifp = if_alloc(IFT_ETHER);
 @@ -2066,8 +2085,7 @@ create_netdev(device_t dev)
  exit:
  	gnttab_free_grant_references(np->gref_tx_head);
  out:
 -	panic("do something smart");
 -
 +	return (err);
  }
  
  /**
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
>Unformatted:
