xen 2.0 tools hacking.

[Manuel Bouyer <bouyer%antioche.lip6.fr@localhost>]

Hi,
so the peoples in the To: have offered help with the xen tools. This is great,
thanks you guys.
I also put Christian in Cc: (I know he his reading port-xen@, but
maybe not on a regular basis) because he may have comments about this.
Also, I hope some of these changes will be integarted back in the xen
distrib.

I propose that we keep this discussion public on port-xen@, so that other
peoples can eventually give comments or propose patches.

The xen 2.0 tools are part of the xen distribution (in xen-2.0/tools) and
I've made a packages for them:
ftp://asim.lip6.fr/outgoing/bouyer/xentools20-package.tgz
I think that to work on this, a xen setup with a NetBSD domain0 kernel is
needed. For testing purposes, using the netbsd-XENU-INSTALL kernel (in the same
ftp directory) as guest OS, with a vbd read-only on the boot disk would be
enouth. So, from a working NetBSD 2.0 system, you'd just need to install
grub, the xen.gz from the xen 2.0 binary distribution, and domain0 NetBSD
kernel (ftp://asim.lip6.fr/outgoing/bouyer/netbsd-XEN0.gz should work on most
hardware). You'll need kernfs mounted on /kern, and a new /dev/xenevt device:
mknod /dev/xenevt c 141 0
Once you have booted netbsd-XEN0, start xend:
/usr/pkg/sbin/xend start
and load the guest OS:
cd /etc/xen
xm create -c nbgest
(you can get ftp://asim.lip6.fr/outgoing/bouyer/nbgest and adapt it for
your system). You should see the guest booting and going to sysinst.


Now, what's needed on the tools. There are several issues:
there are lots of patches in the package, some of them are patches to the
python files. It would be nice if the different behavior between linux and
NetBSD (mostly paths to some files which are different) could be made
conditionnal at run-time, so that we can feed these changes back to the
xen maintainers.

A more important problem is the way xen works with block devices. From a
config entry like:
disk = [ 'phy:/dev/wd0e,hda,r' ]
xend will pass the dev_t and size of /dev/wd0e to the domain0 kernel, and
the dev_t of hda to the guest (so that the guest can choose which "personality"
of the vbd driver is will use). I have 2 issues here:
- the size of /dev/wd0e passed to the kernel is always 0. I guess the
  xen tool isn't using the appropriate call to find the size (I guess it
  just uses the result from stat()).
- to get the dev_t of hda, the xen tool will to a stat() on /dev/hda.
  This means that we can only properly boot a linux guest from a linux domain0,
  or a NetBSD guest from a NetBSD domain0 (creating a linux /dev/hda on the
  NetBSD domain0 works, but it's not something we want to use in long term :)
  I think the xen tools should compute this dev_t from a table giving the
  proper major for each device type and guest OS, instead of relying on
  the domain0's filesysem. I think the xen tools already know the
  guest's OS from the binary kernel being loaded. If not, we can use the
  "builder=" config variable. For now xen doen't know about builder=netbsd,
  but we could clone it from the linux config.

There may also be issues with how the network stuff works, but I've not
analysed this yet. I'll come back on this later, when I have a working
net backend (hopefully before the end of the week).

So, if someone could have a look at these issues (especially the dev_t
problem) it would be really great !

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--