Hi,
On 14/12/2018 17:48, Julien Grall wrote:
On 14/12/2018 17:24, Andrii Anisov wrote:
On 14.12.18 18:26, Julien Grall wrote:
I don't understand how you came up with the conclusion that 128MB will be
removed from Dom0. We only have the requirement that the first bank is at least
128MB. So can you expand it?
IIRC Linux kernel requires that the machine RAM start must be 128MB aligned.
Please try to reference the documentation (or code if lack of documentation)
when making such statement.
AFAICT, Linux 32-bit [1] imposes the kernel to be loaded in the first 128MB of
RAM. Nothing about the 128MB aligned RAM. Linux 64-bit [1] requires to be loaded
at a 2MB aligned address.
So technically allocating the RAM using a 2MB alignment should be enough. Yet we
need to make sure the first bank is at least 128MB.
Look at `allocate_memory_11()`, `min_low_order` variable usage. It affects all
low memory 1:1 allocation and makes all low memory banks 128MB aligned both
start and end.
So that having a module in a low memory poisons the whole 128MB region.
That's definitely an unwanted behavior, but this is not related to the patch
itself. As soon as you hand memory to the allocator, memory can be allocated at
any place in the memory. I am still unsure whether the alignment is due to the
algorithm in allocate_memory_11() or because of the order we pass to the allocator.
Until we fix it, the best recommendation is to keep all the modules close
together at the beginning of the RAM. So you only "waste" 128MB region. I can
add this recommendation in the commit message and potentially documentation.
Answering to myself. Stefano pointed out on IRC that grub/UEFI users are not in
control of the memory layout so this might be an issue for them.
Looking at my GRUB setup, all the modules are loaded together:
(XEN) MODULE[0]: 00000000f2afb000 - 00000000f2b02000 Device Tree
(XEN) MODULE[1]: 00000000f695b000 - 00000000f7f6fa00 Kernel
(XEN) MODULE[2]: 00000000f2c23000 - 00000000f6959200 Ramdisk
[...]
(XEN) Placing Xen at 0x000000099be00000-0x000000099c000000
(XEN) Update BOOTMOD_XEN from 00000000f2b02000-00000000f2c22d81 => 000000099be00
So whether Xen is going to be relocated or not is not going to make much
difference.
Now, let's image the bootloader decides to load the modules in different places
in the memory. Then you will have 4 slots (potential 5 slots) of 128MB used.
That's up to 640MB of low memory not available for Dom0. Relocating Xen may or
may not make available more low memory for Dom0. For instance, in my use case
above, this does not make any change.
This is obviously the worst case scenario. I am pretty sure people would have
seen report if 640MB of low memory was not available for Dom0 and that was a
concern.
So, to be honest, I think this is a non-issue. I am not saying this should not
be fixed. I am saying that the price is minimal compare to allow Xen booting on
platform such as the Hikey and bringing more compliance with the Arm Arm.
Cheers,
Cheers,
[1] Documentation/arm/Booting
[2] Documentation/arm64/booting.txt
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
