Re: [Xen-devel] [PATCH]: Allow Xen to boot/run on large memory (>64G) machines

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 22.02.07 08:50 >>>
>On 22/2/07 00:38, "Chris Lalancette" <clalance@xxxxxxxxxx> wrote:
>
>>      Note that this is not the end of the story, however.  For even larger
>> machines, it can *still* be the case that the allocation in construct_dom0()
>> fails; in particular, if the order goes above 17, it will fail in the same
>> way.
>>  One way to fix it would be to just allocate that memory out of the normal
>> zone
>> for x86_64, as well; however, I'm not sure if this will break anything else.
>> Any comments?
>
>If there are no users of alloc_boot_pages() expecting low memory to be
>returned then we can adjust the implementation of that existing function
>rather than introduce a new one.
>
>As for domain_build() there are two considerations: firstly that the
>allocation is contiguous and secondly that it is from the DMA pool. The
>builder makes simplifying assumptions based on contiguity. The allocation
>from DMA pool I think I've tried to get rid of before -- I think I was
>scuppered by something as simple as the PAE pgdir needing to be allocated
>from low memory. I think we can stop allocating from the DMA pool, at least
>for non-PAE host.

The page allocator changes that I posted a while back probably haven't
been looked at so fat, given the above comments. The patch that kills the
DMA pool changes x86-64 to allocate the dom0 memory without restriction
(i386 has to remain restricted, yet not because of DMA address issues, but
in order to be able to see the memory in the 1:1 mapping).

Likewise, I'm not certain the changes presented here make a lot of sense
in the context of the elimination of the DMA pool and the resulting desire
to unify xen heap and domain heap on x86-64.

Jan

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel