Hi,
On 4/26/19 4:48 PM, Jan Beulich wrote:
On 26.04.19 at 17:38, <[email protected]> wrote:
On 26/04/2019 10:42, Jan Beulich wrote:
On 26.04.19 at 11:19, <[email protected]> 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
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
