Where can one access the source for the initial NetBSD port? It would be a good starting point for a FreeBSD port. -Kip ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> In particular, Xen now supports "user-space domain buiding", > which makes things quite a bit easier -- you get to populate theI''ve read through the xi_build.c code. I believe that there isn''t much to do there except perhaps change the address that the initial page directory gets mapped at.> 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 realI haven''t seen this, all I''ve had to go on is linux/arch/xeno, which is actually fairly adequate. If you could send me a copy of that or tell me where to look I would appreciate it. That would get me further faster than the NetBSD port.> code as the port progresses. It provides some useful debugging > output rather than just having Xen terminate the domain whenever > it attempts something illegal.That sounds more useful than just Hacking printf to use HYPERVISOR_console_write.> > I put together a rough plan for porting FreeBSD in an earlier > email describing various possible Xen projects. I''ve actuallyI read that. I''ve done step 3 and believe that I''ve figured out how to do steps 4 and 5 (now 5 and 6). Having "minimal OS" would greatly accelerate 4 (5).> been having a read through the FreeBSD i386 source over the > weekend. The pmap memory management interface looks very clean,As have I, I agree. All that locore.s really needs to do is read the contents of start_info and then call init386 (modified for xeno) and then mi_startup. It doesn''t look like as many files need to change for FreeBSD as did for linux.> > Having a FreeBSD port would be really cool, and I''d be keen to > help it along / support it. >Thanks for any help you can provide. I''m fairly busy, but this and OS checkpoint/migration are both things I''d like very much to have. I wrote a process level checkpoint/migration facility for FreeBSD and will probably actually end up checking it in to the DragonFly tree. The only part of OS migration that would be genuinely difficult would be keeping the restart latency low. -Kip ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I haven''t seen this, all I''ve had to go on is linux/arch/xeno, which > is actually fairly adequate. If you could send me a copy of that or > tell me where to look I would appreciate it. That would get me further > faster than the NetBSD port.Sorry, it wasn''t checked in. There''s are actually two versions that have evolved independently, one used by the XenoXP guys, the other by Rolf, who is playing around with custom guest OSes. I''ve asked both teams to send me their latest versions of MinimalOS, and I''ll get them checked in and pushed to bkbits later today. [As well as the xeno-1.0.bk tree, I''ve just created a new xeno-unstable.bk tree, which has got a few changes to Xen in preparation for multiprocessor guest OSes. I''m not sure which tree would be best for you to work from. There aren''t going to be any huge changes to the guestOS interface, so I don''t suppose it really matters.] Best, Ian ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
I''ve just checked in and pushed ''extras/mini-os'' into the xeno-unstable.bk tree on xen.bkbits.net It contains a fairly minimal example guest OS with example trap handlers and some debugging support. It''s a useful starting point for porting new guest OSes, or possibly even for teaching purposes. The following command will pull the latest repository: bk clone bk://xen.bkbits.net/xeno-unstable.bk Or, if you already have a repository, use the following to update it: bk pull bk://xen.bkbits.net/xeno-unstable.bk Best, Ian ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel