The following reply was made to PR port-xen/30635; it has been noted by GNATS.

From: jld@panix.com (Jed Davis)
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-xen/30635
Date: Wed, 17 Aug 2005 19:23:23 -0400

 I have here a small patch to xend (for xen 2.0.6, but I don't think
 the affected code has been changed on that branch) that makes it
 behave itself; this is true whether or not the dom0 kernel is using
 the change I described earlier.  I don't know why this isn't an issue
 for all users of xend on other OSes, but apparently it's not.
 
 --- tools/python/xen/xend/XendDomain.py.orig    2005-08-13 01:54:56.000000000 -0400
 +++ tools/python/xen/xend/XendDomain.py 2005-08-13 01:55:17.000000000 -0400
 @@ -147,7 +147,10 @@
              domid = str(d['dom'])
              doms[domid] = d
          dlist = []
 -        for config in self.domain_db.values():
 +        domkeys = map(int, self.domain_db.keys())
 +        domkeys.sort()
 +        for domkey in domkeys:
 +            config = self.domain_db.get(str(domkey))
              domid = str(sxp.child_value(config, 'id'))
              if domid in doms:
                  d_dom = self._new_domain(config, doms[domid])
 
 I suspect that this is not the Right solution from the perspective of
 xend's architecture, which I do not understand, but it works.  I also
 don't pretend to know what the Right Thing to do with
 IOCTL_PRIVCMD_MMAP at this point is.
 
 For those that read python: the change in traversal order is needed
 because of a data dependency encountered 11 method calls down the
 stack, in some code that I think is shared between state-recovery and
 domain creation -- the backend domain for the domU's virtual devices
 needs to have been recovered first so that a lookup (which seems
 pointless in this context) of it won't fail, and so raise an exception
 whose handling (SFAICT) sort of tries to destroy that domU and then
 goes off the rails entirely.  (This might be a little less disastrous
 with xen 2.0.7; I haven't checked yet.)
 
 I guess I get to deal with the upstream now.
 
 -- 
 Jed Davis
 jld@panix.com