From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- microkernel/mach/gnumach/ports/xen.mdwn | 208 +++++++++++++++++++++++++++++++- 1 file changed, 206 insertions(+), 2 deletions(-) (limited to 'microkernel/mach/gnumach/ports') diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index c6023786..a8a1fcbf 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, -Inc."]] +[[!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 @@ -96,6 +96,176 @@ Download http://youpibouh.thefreecat.org/hurd-xen/pv-grub.gz into /boot, and use 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: @@ -108,6 +278,23 @@ You will also need to use the parted storeio module for the /dev entries, for in 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]]. @@ -125,3 +312,20 @@ 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 -- cgit v1.2.3