[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!toc]] # Xen dom0, hypervisor /!\ Now that GNU Mach handles PAE you can use a PAE-enabled hypervisor. You can either get binaries at or build them yourself. - Copy `gnumach-xen-pae` and `hurd-modules` to your dom0 /boot. If you still have a non-PAE hypervisor, use `gnumach-xen-nonpae` instead. - Copy `hurd` into `/etc/xen`, edit it for fixing access to your hurd / and swap # GNU/Hurd system /!\ You need an already installed [[GNU/Hurd_system|hurd/running]]. If you have a free partition, you can fdisk to type 0x83, create a filesystem using: sudo mke2fs -b 4096 -I 128 -o hurd /dev/sda4 Replace /dev/sda4 with your partition. Install and use crosshurd to setup a GNU/Hurd system on this partition. # /etc/xen/hurd configuration Here is a sample /etc/xen/hurd configuration kernel = "/boot/gnumach-xen-pae" memory = 256 disk = ['phy:sda4,hda,w'] extra = "root=device:hd0" vif = [ '' ] ramdisk = "/boot/hurd-modules" Do not give more than 580MB memory (due to bootstrap limitations, it's not easy to map more). Suggestions about [[networking_configuration]] are available. If you need stable MAC addresses, use a syntax like `vif = [ 'mac=00:16:3e:XX:XX:XX, bridge=br0' ]`. # Running Hurd with Xen To run Hurd with Xen, use: xm create -c hurd and gnumach should get started. Proceed with native-install. export TERM=mach ./native-install - If `xm` complains about networking (`vif could not be connected`), it's Xen scripts' fault, see Xen documentation for how to configure the network. The simplest way is network-bridge with fixed IPs (note that you need the bridge-utils package for this). You can also just disable networking by commenting the vif line in the config. - If `xm` complains `Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n')`, you most probably have a PAE-enabled hypervisor and a non-PAE gnumach. Either install and boot non-PAE hypervisor and kernel, or rebuilt gnumach in PAE mode. # Building from sources If you want to generate these images, first get the `gnumach-1-branch-Xen-branch` branch from gnumach CVS. Then look for "Ugly" in `kern/bootstrap.c`, how to generate `hurd-modules` is explained there, and you'll have to fix `EXT2FS_SIZE` and `LD_SO_SIZE` by hand. Then use ./configure --enable-platform=xen make The current `hurd-modules` was built from the debian packages `hurd 20070606-2` and `libc0.3 2.6.1-1`. /!\ This means that when using this image, your GNU/Hurd system also needs to be a glibc version 2.6 or later-based one! # `pv-grub` From Xen 4.0 on you can run the GNU Hurd directly using `pv-grub`, without the need to [prepare a special bootstrap image](http://youpibouh.thefreecat.org/hurd-xen/build_hurd-modules) (like an initrd). Download http://youpibouh.thefreecat.org/hurd-xen/pv-grub.gz into /boot, and use the following for instance: kernel = "/boot/pv-grub.gz" memory = 256 disk = ['phy:sda4,hda,w'] extra = "(hd0,1)/boot/grub/menu.lst" vif = [ '' ] extra is now the path to the grub config file. ## IRC, freenode, #hurd, 2013-11-09 youpi: would a limitation of 32 modules to hurd in pvgrub2 be a problem? *31 phcoder: probably not youpi: ok youpi: gnumach goes into infinite loop with "warning: nsec 0x000096dae65d2697 < lastnsec 0x000096db11dee20d". Second value stays constant, first value loops from 0x000096da14968a59 to 0x000096db08bf359e. Not sure if the problem is on GRUB or gnumach ide loops?! that's the time coming from the hypervisor not a problem from GRUB anyway Yes, loops in steps of around 0x40 and comes back regularly. Mmm, maybe it could be grub not properly setting up hyp_shared_info.vcpu_info[], actually i.e. the mfn in boot_info.shared_info I don't think we write to shared page at all could gnumach suffer from overflow on fast CPU? next_start.shared_info = grub_xen_start_page_addr->shared_info; And shared_info is machine address, so no need to adjust it tsc_shift can be negative. Does gnumach handle this? yes here it's the base which doesn't change, actually Do you mean this: system_time = time->system_time; ? But wait: ((delta * (unsigned64_t) mul) >> 32) this overflows after 2^32 nanoseconds which is about 4 seconds I think this is the mistake which is more or less what I see Let me make a patch does xen have some tickless feature now? I'd expect the clock to get updated at least sometimes during 4 seconds :) Hm, can't compile master: ./include/mach/xen.h:52:18: error: ‘MACH2PHYS_VIRT_START_PAE’ undeclared (first use in this function) #define PFN_LIST MACH2PHYS_VIRT_START_PAE Here is the patch: http://paste.debian.net/64857/ it's defined in xen/public/arch-x86/xen-x86_32.h yes it is. Let's see why it's not included Hm, for some reason it pulls 64-bit headers in how do you cross-compile? I use ./configure --host=i686-gnu CC='gcc -m32' LD='ld -melf_i386' Yes. GRUB adds those itself youpi: confirmed: my patch solves the problem any yes: I tried with unpatched master and it fails ok phcoder: thanks! Now I get plenty of "getcwd: cannot access parent directories: Inappropriate file type or format". But I don't think it's grub-related what do you get before that? perhaps ext2fs doesn't get properly initialized which module commande line do you get in the boot log? perhaps it's simply a typo in there http://paste.debian.net/64865/ $(task-create) $(task-resume) is missing at the end of the ext2fs line indeed in your paste it stops at $( this is at the end of my console. I believe it to be cosmetic. Let me reset console to some sane state ok the spurious event at the start is probably worth checking up it looks like events that pvgrub2 should have eaten (in its own drivers, before finishing shutting them down) when redirecting console to file: http://paste.debian.net/64868/ could swapon have sth to do with it? I'd be surprised my guess it's because I use older userland (debian about May) and new kernel (fresh from master) the kernel hasn't really changed you could rebuild the may-debian kernel with your patch to make sure but probably better trying to fix swapon first, at least (even if that'd surprise me) "trying fixiing* swapon", actually it makes a difference :) We actually never eat event on evtchn, we look into buffers to check for response ah, that's why you should really eat the events too in principle it wouldn't hurt not to, but you'd probably get surprises youpi: would doing EVTCHNOP_reset at the end be enough? possibly, I don't know that one looks like a good thing to do before handing control, indeed /* Clear pending event to avoid unexpected behavior on re-bind. */ evtchn_port_clear_pending(d1, chn1); yes, it does clear the pending events http://paste.debian.net/64870/ I did this: http://paste.debian.net/64871/ well, closing the event channels would be a good idea too (reset does not only clear pending events, it also closes the event channels) well we can't close console one. So it leave to close disk ones (the ones we allocated) http://paste.debian.net/64875/ New log: http://paste.debian.net/64876/ (swapon fixed, given 1G of memory) ok, so it really is something else looks like there is a space after $(task-resume) but can't tell if it's real or comes from message tottally artefact youpi: this happens when booted in qemu with old kernel now. Now my bet is on weird fs corruption or because I accessed it with Linux in rw. In any case I feel like it's time to call it a port and commit I'd say so, yes Let's look what's remaining: vfb, vkbd and vif: don't need them for first port commit. Hm, there is an issue of default configfile. What is pvgrub default behaviour? iirc it just enters the shell I had implemented vfb and vkbd to get the graphical support, but that's optional indeed vif is useful for netboot only ah, no, by default it runs dhcp --with-configfile youpi: port committed to trunk \o/ I was lamenting for 5 years that that wasn't happening :) Citrix could have asked one of his engineers to work on it, really documentation on using the port is still missing though amazon EC2 users will be happy to upgrade from pv-grub to pv-grub2 :) I asked some amazon guy at SuperComputing whether he knew how many people were using pv-grub, but he told me that was customer private information Another interesting idea would be to switch between 64-bit and 32-bit domains somehow yes, we were discussing about it at XenSource when I implemented pv-grub that's not really an easy thing pvh would probably help there, again in the end, we considered that it was usually not hard to select a 32bit or 64bit pv-grub depending on the userland bitness we considered adding a hypercall to change the bitness of a domU, but that's really involved Well when you discussed i386 domains were still around now it's only PAE and amd64 and they are very similar. Only few gdt differ well, switching from 32-PAE to 64 is not *so* hard since a 32bit-loaded OS can fit in 64bit the converse is more questionable of course yes still, it's really not easy for the hypervisor it'd mean converting stuff here and there most probably missing things here and there :) Ok, not that important anyway we felt it was too dangerous to promise the feature as working :) heh, 5000 lines patch, just like my patch adding support to Mach :) BTW do you know how to check if kernel supports dom0 ? Apparently there is feature "privilegied" and dom0 kernels are supposed to have it in notes but my linux one doesn't even though I'm in xen now it's XENFEAT_dom0 called dom0 in the notes http://paste.debian.net/64894/ well, maybe the hypervisor doesn't actually check it's there phcoder: what does grub-mkstandalone? puts all modules in memdisk which is embed into core ah, ok we didn't have to care about that in grub1 indeed :) # Partitions You will need the following notation for the gnumach root= parameter: root=part:2:device:hd0 to access the second partition of hd0, for instance. You will also need to use the parted storeio module for the /dev entries, for instance: settrans -fgap /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0 ## IRC, freenode, #hurd, 2013-11-09 youpi: now I get "hd0: dom0's VBD 768 (/home/phcoder/diskimg/debian-hurd-20130504.img,w) 3001MB" but "start ext2fs: ext2fs: device:hd0s1: No such device or address" disk = [ 'file:/home/phcoder/diskimg/debian-hurd-20130504.img,hda,w' ] Hm, using "disk = [ 'phy:loop0,hda1,w' ]" instead worked (loop0 is an offset loop) yes, xen disks don't support partitioning and we haven't migrated userland to userland partitioning yet [[hurd/libstore/part]]. # Miscellaneous [[Internals]]. [[!GNU_Savannah_task 5468]], [[!GNU_Savannah_task 6584]]. # Host-side Writeback Caching Optimization possible as it is with [[QEMU|hurd/running/qemu/writeback_caching]]? IRC, freenode, #hurd, 2011-06-08 youpi: does xen provide disk caching options ? through a blktap, probably ok # IRC, freenode, #hurd, 2013-11-09 youpi: debian-hurd-20130504.img apparently has a kernel without xen note. Do I have to do sth special to get xen kernel? phcoder: there's the -xen package for that I haven't made the kernel hybrid youpi: easiest way is probably to have different entry points. You could even just link both of them at different addresses and then glue together though it's not very efficient it's also about all the privileged operations that have to be replaced with PV operations PVH will help with that regard youpi: btw, I recommend compiling xen kernel for 686 and drop non-pae