Comment 3 for bug 686692

Not the solution yet, unfortunately, but looking at bug #667796, we found that XEN_MAX_DOMAIN_MEMORY limits the memory a domU is reporting. Looking at Natty, this has actually changed to a fixed config option of 128GB. But this went with a quite big change to the mmu code and only changing the value back to 70 is not enough to make it work again. But at least the following commit may be a start to look at:

commit 58e05027b530ff081ecea68e38de8d59db8f87e0
Author: Jeremy Fitzhardinge <email address hidden>
Date: Fri Aug 27 13:28:48 2010 -0700

    xen: convert p2m to a 3 level tree

    Make the p2m structure a 3 level tree which covers the full possible
    physical space.

    The p2m structure contains mappings from the domain's pfns to system-wide
    mfns. The structure has 3 levels and two roots. The first root is for
    the domain's own use, and is linked with virtual addresses. The second
    is all mfn references, and is used by Xen on save/restore to allow it to
    update the p2m mapping for the domain.

    At boot, the domain builder provides a simple flat p2m array for all the
    initially present pages. We construct the two levels above that using
    the early_brk allocator. After early boot time, set_phys_to_machine()
    will allocate any missing levels using the normal kernel allocator
    (at GFP_KERNEL, so it must be called in a normal blocking context).

    Because the early_brk() API requires us to pre-reserve the maximum amount
    of memory we could allocate, there is still a CONFIG_XEN_MAX_DOMAIN_MEMORY
    config option, but its only negative side-effect is to increase the
    kernel's apparent bss size. However, since all unused brk memory is
    returned to the heap, there's no real downside to making it large.