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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.04.19 at 11:19, <Julien.Grall@xxxxxxx> wrote:
> On 26/04/2019 10:12, Jan Beulich wrote:
>>>>> On 25.04.19 at 23:27, <Julien.Grall@xxxxxxx> wrote:
>>> On 25/04/2019 18:51, Stefano Stabellini wrote:
>>> For a first we need to gather feedback from contributors that know a bit
>>> more of the code that may be affected. AFAICT, there are only two pieces
>>> where we hand over memory to common code:
>>>       - PDX: The problem is passing 0 to pdx_init_mask() will result to a
>>> ~0 mask defeating the compression later on.
>> 
>> On x86 the function gets called only for memory blocks above 4Gb.
>> Question is whether on Arm you also have some ad hoc boundary
>> below which there's no point to look for bits to compact. If not I
>> wonder why you call the function at all; at the very least (as you
>> seem to imply) it shouldn't be called when
>> bootinfo.mem.bank[0].start is zero.
> 
> 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.

>>>       - Buddy allocator: Jan has been suggesting to stick a check in
>>> init_xenheap_pages(). This would go the other ugliness existing to deal
>>> with the buddy allocator.
>> 
>> And this would then also take care of future architectures Xen may
>> get ported to. (No idea what other ugliness you refer to.)
> 
> 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.

Jan



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