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

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 4/26/19 4:48 PM, Jan Beulich wrote:
> > > > 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.
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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel