The following reply was made to PR kern/37370; it has been noted by GNATS.

From: Ronald Roskens <ronr@econet.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/37370: xen dom0 kernel does not support guest domU's on
 dk wedges
Date: Mon, 12 Nov 2007 13:25:09 -0600

 This is a multi-part message in MIME format.
 --------------070806060508000406070000
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 ronr@econet.com wrote:
 >> Number:         37370
 >> Category:       kern
 >> Synopsis:       xen dom0 kernel does not support guest domU's on dk wedges
 >> Confidential:   no
 >> Severity:       non-critical
 >> Priority:       low
 >> Responsible:    kern-bug-people
 >> State:          open
 >> Class:          sw-bug
 >> Submitter-Id:   net
 >> Arrival-Date:   Mon Nov 12 17:35:00 +0000 2007
 >> Originator:     Ronald Roskens
 >> Release:        NetBSD 4.0RC4
 >> Organization:
 >> Environment:
 > NetBSD xendom0 4.0_RC4 NetBSD 4.0_RC4 (LOCAL_XEN3_DOM0) #0: Fri Nov  9 21:39:02 CST 2007  root@xendom0:/usr/src/sys/arch/i386/compile/LOCAL_XEN3_DOM0 i386
 >> Description:
 > After enabling dkwedges (adding drvctl, and the assorted DKWEDGE_* to the kernel config file), bootup into a XEN DOM0 environment using the /dev/dk* devices. Attempt to create a new domU, but watch it hang while probing disks. In dom0's dmesg:
 > 
 > xbdback backend/vbd/7/3: can't ioctl device 0xa805: 25
 > xvif7.0: Ethernet address aa:00:00:01:00:02
 > xbd backend: attach device vnd0d (size 495020) for domain 7
 > xbd backend 0x3 for domain 7 using event channel 28
 > xbd backend 0x603 for domain 7 using event channel 29
 > 
 > The xen dom0 device xbdback is attempting to do a DIOCGPART ioctl on the  dkwedge device and is failing.
 > 
 > ==== xen config ====
 > #kernel = "/netbsd-XEN3_DOMU"
 > kernel = "/netbsd-INSTALL_XEN3_DOMU"
 > 
 > memory = 64
 > name = "nbsd"
 > vif = [ 'mac=aa:00:00:00:00:02, bridge=bridge1' ]
 > disk = [ 'phy:/dev/dk5,wd0d,w', 'file:/d/xen/ISOs/netbsd-4-0-rc4-i386cd.iso,cd0d
 > ,r' ]
 > 
 > root = "/dev/wd0d"
 > ==== end xen config ====
 > 
 > 
 >> How-To-Repeat:
 > 1) Create a new XEN3_DOM0 kernel adding:
 > 
 > pseudo-device   drvctl
 > options         DKWEDGE_AUTODISCOVER
 > options         DKWEDGE_METHOD_BSDLABEL
 > options         DKWEDGE_METHOD_GPT
 > options         DKWEDGE_METHOD_MBR
 > 
 > 2) Boot into new XEN3_DOM0 kernel, and setup a raw/phy partition for dom0
 > 
 > disklabel -e wd0
 > ** add slice i
 > dkctl wd0 addwedge wd0i 64645056 21564144 unknown
 > 
 > 3) Start up guest domU, and it hangs while probing devices. You have to hit ESC and run 'xm destroy <domu>' to kill the guest domU.
 > 
 > 
 >> Fix:
 > 
 
 The attached patch lets me use a dk<num> wedge as a physical device for 
 a xen instance. Note: this patch is against a 4.0RC4 source tree, though 
 it doesnt look like the function being patched has changed since rev 1.3.
 
 xbd backend: attach device dk5 (size 2114784) for domain 1
 xvif1.0: Ethernet address aa:00:00:01:00:02
 xbd backend 0x3 for domain 1 using event channel 16
 
 Only real annoyance at this point is that dkwedge does not automatically 
 create dk<num> instances for all disk partitions. I had to set the 
 filesystem type in the disklabel to 4.2BSD to have it autoconfigured at 
 bootup.
 
 --------------070806060508000406070000
 Content-Type: text/plain;
  name="xbdback_xenbus.c.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="xbdback_xenbus.c.patch"
 
 Index: sys/arch/xen/xen/xbdback_xenbus.c
 ===================================================================
 RCS file: /cvsroot/src/sys/arch/xen/xen/xbdback_xenbus.c,v
 retrieving revision 1.3
 diff -b -u -r1.3 xbdback_xenbus.c
 --- sys/arch/xen/xen/xbdback_xenbus.c	14 Nov 2006 22:14:56 -0000	1.3
 +++ sys/arch/xen/xen/xbdback_xenbus.c	12 Nov 2007 19:07:05 -0000
 @@ -548,6 +548,7 @@
  	const char *devname;
  	int major;
  	struct partinfo dpart;
 +	struct dkwedge_info dkw;
  
  	err = xenbus_read_ul(NULL, xbusd->xbusd_path, "physical-device",
  	    &dev, 10);
 @@ -609,18 +610,29 @@
  	}
  	VOP_UNLOCK(xbdi->xbdi_vp, 0);
  	err = VOP_IOCTL(xbdi->xbdi_vp, DIOCGPART, &dpart, FREAD, 0, NULL);
 -	if (err) {
 +	if (err == 0) {
 +		xbdi->xbdi_size = dpart.part->p_size;
 +		printf("xbd backend: attach device %s%d%c (size %d) "
 +		    "for domain %d\n", devname, DISKUNIT(xbdi->xbdi_dev),
 +		    DISKPART(xbdi->xbdi_dev) + 'a', xbdi->xbdi_size, xbdi->xbdi_domid);
 +		goto again;
 +	}
 +
 +	err = VOP_IOCTL(xbdi->xbdi_vp, DIOCGWEDGEINFO, &dkw, FREAD, 0, NULL);
 +	if (err == 0) {
 +		xbdi->xbdi_size = dkw.dkw_size;
 +		printf("xbd backend: attach device %s%d (size %d) "
 +		    "for domain %d\n", devname, DISKPART(xbdi->xbdi_dev),
 +		    xbdi->xbdi_size, xbdi->xbdi_domid);
 +		goto again;
 +	}
 +
  		printf("xbdback %s: can't ioctl device 0x%x: %d\n",
  		    xbusd->xbusd_path, xbdi->xbdi_dev, err);
  		xbdi->xbdi_size = xbdi->xbdi_dev = 0;
  		vn_close(xbdi->xbdi_vp, FREAD, NOCRED, NULL);
  		xbdi->xbdi_vp = NULL;
  		return;
 -	}
 -	xbdi->xbdi_size = dpart.part->p_size;
 -	printf("xbd backend: attach device %s%d%c (size %d) "
 -	    "for domain %d\n", devname, DISKUNIT(xbdi->xbdi_dev),
 -	    DISKPART(xbdi->xbdi_dev) + 'a', xbdi->xbdi_size, xbdi->xbdi_domid);
  
  again:
  	xbt = xenbus_transaction_start();
 
 --------------070806060508000406070000--