Currently, initrd size is limited by the virtual space available in the
initial mapping. Linux in particular, however, has no need for the
initrd to be mapped at all - it deals with it in terms of physical
addresses, and hence this limitation can be easily removed on the
kernel side (patch - not applicable to the 2.6.18 or pv-ops trees -
attached here for reference).
Additionally, the initrd could get copied around up to three times
(once [32-bit only] in the early boot relocation code, once when
coalescing modules to a single physical address area, and once
when placing it into Dom0's initial mapping). Obviously, when the
initrd is large, this can visibly delay the boot process, but it can
be reduced to a single copy (or, in rare cases, to no copy at all;
in a special case [32-on-64 with huge amounts of memory] two
copy operations may still be needed).
Further, no provisions seem to have existed to avoid a collision
of the area Xen gets relocated to (on x86-64) with any of the
modules.
Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
xen-x86_64-unmapped-initrd.patch
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|