Re: FW: [Xen-devel] Xen + other stuff?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> Sorry to be obtuse, but I am quite a detailed technical guy, and I would
> like to understand the limitation at the code level.
> 
> I looked at the code in xi_build.c (is that the right place)? I saw that the
> domain 0 code was copying in the kernel, and initrd images in 1 page at a
> time (and deallocating the pfn after each page was copied). The only thing
> that looked like needed a large chunk of domain 0 virtual address space was
> the pfn array? Is that what is behind the 800mb limit?
> 
> Is the 800Mb an 800Mb physical limit? Could the guests have larger virtual
> address spaces, and just swap (within the guest)?

The limitation is that, without CONFIG_HIGHMEM, Linux requires a
permanent mapping for every physical page that it owns. Since the
Linux kernel's virtual address space starts at 0xC000000, and Xen
reserves all address space above 0xFC000000, that means that there's
about 0xFC000000-0xC0000000 == 0x3C000000 == 960MB of virtual address
space that Xenolinux could possibly use. Some of this is burned on
vmalloc and ioremap areas, bringing thee actual amount available for
permanent virtual-to-physical mapping down to not much more than 800MB.

With CONFIG_HIGHMEM, Linux no longer needs a permanent mapping for
every page it owns. Pages in high memory can be temporarily mapped in
(just as the domain builder does in user space). We'll port this
config option real soon now, and that will mean that every Xenolinux
instance could be allocated anything up to 4GB.

 -- Keir


-------------------------------------------------------
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