[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] xen/arm: skip first page when RAM starts at 0x0
Hi Jan,
On 26/04/2019 10:42, Jan Beulich wrote:
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.
Ah, the code makes a bit more sense on the x86 side. Is there any reason to
limit to address bit 32 .. 51?
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.
- 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.
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?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
