Re: [Xen-devel] [PATCH] xen/arm: skip first page when RAM starts at 0x0

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.04.19 at 17:38, <julien.grall@xxxxxxx> wrote:
> On 26/04/2019 10:42, Jan Beulich wrote:
>>>>> On 26.04.19 at 11:19, <Julien.Grall@xxxxxxx> wrote:
>>> So how does the PDX work for memory below 4GB? Do you still call
>>> pfn_to_pdx or those pages?
>> 
>> Of course. We merely never compress any of the low 32 address
>> bits, i.e. our choice is limited to address bits 32 ... 51.
> 
> Ah, the code makes a bit more sense on the x86 side. Is there any reason to 
> limit to address bit 32 .. 51?

Well, there being various special things immediately below 4Gb
there's simply little point in trying to squash any of the lower bits.

> For Arm, we can't compress bits 0 ... 30 due to the buddy allocator (see 
> pfn_pdx_hole_setup). So we could ignore the first 1GB of RAM.

Bits 0 ... 30 would be the first 2Gb afaict.

>>> See:
>>>
>>> /*
>>>    * Yuk! Ensure there is a one-page buffer between Xen and Dom zones, to
>>>    * prevent merging of power-of-two blocks across the zone boundary.
>>>    */
>>>
>>> And the 0 is yet another hack for the buddy allocator.
>> 
>> Ah, this one. Is this actually an issue on Arm32? ix86 needed
>> to deal with the situation because its direct map range was
>> 12Mb in size, i.e. not a power of two. If it's not an issue (I
>> can't really figure it out considering there are no DIRECTMAP_*
>> constants for Arm32 at all, only XENHEAP_* ones), I'd suggest
>> putting this ugliness in an #ifdef using a CONFIG_* option not
>> selected by any presently supported arch.
> 
> On Arm32, the size of the xenheap depends on the platform. It is calculated 
> by 
> setup_mm in arch/arm/setup.c. From my understanding it may not be a power of 
> 2, 
> so we would be affected by the problem you mention here.
> 
> May I ask why it is currently not be an issue on x86? Do you always pass a 
> power 
> of 2 to init_xenheap_pages?

No, it's because CONFIG_SEPARATE_XENHEAP is undefined on
(64-bit) x86, i.e. there simply is no boundary between both heaps.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel