> Yes, this worked, thanks!
Phew! It's been a hard slog...
> 1. mkdir xen-new ; cd xen-new
> 2. bk clone bk://xen.bkbits.net/xeno-unstable.bk
> 3. ./xeno-unstable.bk/tools/misc/xen-clone
> bk://xen.bkbits.net/xeno-unstable.bk
What you've done here is actually a bit odd and likely to lead to
confusion: the xen-clone is going to pull another copy of the
repository you're going to end up with two copies.
I'd advise just taking a local copy of the xen-clone script (or
downloading it from the website) rather than cloning the
repository just to get it (it doesn't change frequently).
tip: you can then edit it to create your own site-specific
section such that the install/boot directory is a link to /boot,
hence 'make install' will just work without you having to do the
copy manually.
> I noted that ReiserFS was not in this kernel, so:
>
> 4. cd xeno-clone/xenolinux-2.4.22
> 5. edited .config to add ReiserFS support (could "make menuconfig")
> 6. make dep; make bzImage
> 7. cp arch/xeno/boot/image.gz ../install/boot/xenolinux.gz
You can do this by using the 'make install' target.
If you wanted to rebuild xen and the xi_* tools, just cd into
'xeno.unstable.bk' and do 'make install'.
[memo to self: perhaps we should create a "tools/misc/xen-build-all"
script to do both of the above?]
> Then, copied the images to /boot:
> 8. cd ../install/boot
> 9. (as root) cp image.gz /boot/ ; cp xenolinux.gz /boot/
>
> My (working) /boot/grub/menu.lst is:
>
> title xen
> root (hd0,0)
> kernel /image.gz dom0_mem=768000 ser_baud=115200 noht
> module /xenolinux.gz root=/dev/sda2 ro console=xencons0 DOMID=0
Fine.
> This works fine with a 768MB memory limit. However, when
> I tried it with "dom0_mem=1024000" I got an immediate reboot
> after the kernel loaded. As mentioned earlier, this machine
> has 2GB of physical RAM, which seems to be mapped contiguously.
The current xenolinux config does not support CONFIG_HIGHMEM4G,
hence you're limited to ~800MB (the kernel virtual address space
contains a linear mapping of _all_ physical memory, hence the
limit). Adding CONFIG_HIGHMEM4G support (which will give you up
to 4GB of RAM per guest) should be straightforward but we haven't
done this as no-one has needed it before. You GRID guys have too
much money ;-))
Adding support for CONFIG_HIGHMEM64G would be more of a pain, as
we'd have to implement PAE36 support in Xen.
Rather than trying to start one really big guest, can you start a
couple of 800MB ones?
It's unfortunate that domain0 exits rather than just mapping all
of the memory it can handle (and ideally giving the rest
back). We can fix this.
Adding CONFIG_HIGHMEM4G should be on the todo list. Making it
work should mainly be a case of putting code that's in
arch/i386 back into arch/xeno (it was removed in the early days
for simplicity, and can now safely go back).
> Thanks again for this help! On to virtual domains, next...
It's good to have people pushing the operational envelope...
Ian
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home