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

From: Julien Grall <julien.grall@arm.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <stefanos@xilinx.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	206497@studenti.unimore.it,
	xen-devel <xen-devel@lists.xenproject.org>,
	nd@arm.com
Subject: Re: [PATCH] xen/arm: skip first page when RAM starts at 0x0
Date: Fri, 26 Apr 2019 22:31:04 +0100	[thread overview]
Message-ID: <72a0eee1-1d29-2368-3737-d37f7a4926c6@arm.com> (raw)
In-Reply-To: <5CC3283A0200007800229832@prv1-mh.provo.novell.com>

Hi,

On 4/26/19 4:48 PM, Jan Beulich wrote:
>>>> On 26.04.19 at 17:38, <julien.grall@arm.com> wrote:
>> On 26/04/2019 10:42, Jan Beulich wrote:
>>>>>> On 26.04.19 at 11:19, <Julien.Grall@arm.com> 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.

Sorry I messed us my maths. I meant 0 ... 29 (MAX_ORDER = 18).

@Stefano, do you think you can have a look at it?

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

Oh, somehow I thought it was separated. Ok, so I would keep the code as 
is in init_xenheap_pages then.

But it occured to me that we may want to put the check in 
init_heap_pages() rather than init_xenheap_pages() as we also want to 
cover domheap.

Cheers,

-- 
Julien Grall

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