Re: [Xen-devel] NetBSD port

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>]

> Where can one access the source for the initial NetBSD port?
> It would be a good starting point for a FreeBSD port.

I'll ask Anil to dig out the code for the aborted NetBSD port
out, but I'm not sure it'll actually be a good starting point
because Xen has progressed quite a bit since then.

In particular, Xen now supports "user-space domain buiding",
which makes things quite a bit easier -- you get to populate the
initial memory, registers and page table base for the new domain
from a normal user-space process running in domain0, so avoid all
of the usual contortions of pulling yourself up from your boot
laces. We also now have something called the "minimal OS" which
contains useful default code for all the various trap and
interrupt handlers, which you can then override with the real
code as the port progresses. It provides some useful debugging
output rather than just having Xen terminate the domain whenever
it attempts something illegal.

I put together a rough plan for porting FreeBSD in an earlier
email describing various possible Xen projects. I've actually
been having a read through the FreeBSD i386 source over the
weekend. The pmap memory management interface looks very clean,
so I don't think a port will be difficult (in contrast, Win XP
was a right pain in the butt as direct *pte= updates are
sprinkled in literally hundreds of places over the HAL)

Having a FreeBSD port would be really cool, and I'd be keen to
help it along / support it.

Ian


>From previous email: (slightly updated)

FreeBSD 4.8 port
================

We really need a FreeBSD port. The aborted NetBSD port isn't a
very good starting point as Xen has evolved quite a bit since
then. Here's a step by step guide to doing the port:

1. learn how to build and boot a standard i686 FreeBSD kernel

2. Copy the i386 directory to i386-xeno and hack the makefiles
appropriately.

3. hack the kernel so that it doesn't use the top 64MB of virtual
address space. Close down the kernel segment descriptors and boot
the kernel on a normal i386 system to ensure its not using that
part of the VA space. 

4. To simplifying the initial port, hack the CPU features bit
vector to clear the following features: 4MB superpages, global
pages, 36bit addressing (PAE).

5. identify the 32 bit protected mode kernel entry point
(locore). Graft the xen 'minimal OS' code on the front to set up
stacks, trap handlers etc.

6. Hack the user space domain builder so that it configures the
initial page tables how FreeBSD wants them (this is easier than
doing it in the guestOS startup code).

7. hack 'printf' so that it does a HYPERVISOR_CONSOLE_WRITE so
that we get debugging output early, before console/syslog support
is up in the guest

8. Grep the tree looking for privileged instructions. Turn them
into break points so you can tell when you hit them.

9. Use the domain builder to boot the i386-xeno kernel. See where
the guestos explodes (turn on debugging in Xen to get some useful
info about why Xen felt it necessary to terminate the guestos).

10. When it explodes, it'll probably be faulting on a privileged
instruction, or page table write. Fix the code to use the proper
Xen call. Be conservative and flush the Xen request queue after
every operation -- we can optimise latter.

11. Repeat steps 9 and 10 until you get "unable to mount root file
system". Have a celebratory beer, you've very close. 

12. Next, port the Xen network device driver code (should be
pretty easy). Configure the kernel for a static command line IP
config (ip=169.254.1.1/16) and NFS root. Run a server in domain0
(server=169.254.1.0).

13. You should then have a working FreeBSD system. Give it a good
workout by running some demanding Apps to generate a validation
test suite.

14. Port the Block device driver from Linux. Grant access to it
from domain0, then make a file system on it and try it out. Copy
the filesystem from the NFS serve on to it, then Boot from it.

15. Optimise the port by removing the flush after every pte_queue
call. E.g. in linux it's only necessary to do a flush when
dropping the lock on a "vma", as this is sufficient to prevent
read-after-write races. Use the validation suite to check you
haven't been overly cunning. 

16. I buy you a very good dinner.










-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel