[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH for-4.12 v2 2/2] xen/arm: Stop relocating Xen





On 14.12.18 19:48, Julien Grall wrote:
Please try to reference the documentation (or code if lack of documentation) 
when making such statement.

Ah, yes, sure.

AFAICT, Linux 32-bit [1] imposes the kernel to be loaded in the first 128MB of 
RAM. Nothing about the 128MB aligned RAM.

Right, the documentation sets a restriction for a compressed image to be loaded 
in the first 128MB of RAM. But the comment in a decompressor code (and the code 
itself) explicitly refer alignment [11].
Calculating a RAM start address with this mask [22] give us a wrong value if 
the real physical address is 64MB aligned, not 128MB. Then crash on 
decompressing. You know, I stepped into that with J6 (arm32) while setting up 
thin Dom0 with only 64MB RAM.

Linux 64-bit [1] requires to be loaded at a 2MB aligned address.

Great, 64-bit Linux documentation directly refers the alignment :)

So technically allocating the RAM using a 2MB alignment should be enough.

For 64-bit and, maybe, raw 32-bit Linux kernel images.
For 32-bit compressed Linux kernel - still 128MB aligned first bank is 
required. It can be changed on kernel side by setting ZRELADDR, but we can't 
designate that from XEN runtime.

Yet we need to make sure the first bank is at least 128MB.

Well, I'm not sure the ARM64 documentation [33] or implementation mention the 
size of the first bank. Except it should be enough to hold the kernel image 
[44].
Also I would not treat [55] as a strict requirement to have 128MB in the first 
bank. But we can stick at that to make things easier.

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.

I'm totally agree that it is not related to the code changes done by the patch. 
But leads to the patch message change.

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.

It might work for the current code.

I can add this recommendation in the commit message and potentially 
documentation.

I vote for this.

[11] 
https://elixir.bootlin.com/linux/v4.20-rc7/source/arch/arm/boot/compressed/head.S#L217
[22] 
https://elixir.bootlin.com/linux/v4.20-rc7/source/arch/arm/boot/compressed/head.S#L236
[33] 
https://elixir.bootlin.com/linux/v4.20-rc7/source/Documentation/arm64/booting.txt
[44] 
https://elixir.bootlin.com/linux/v4.20-rc7/source/Documentation/arm64/booting.txt#L129
[55] 
https://elixir.bootlin.com/linux/v4.20-rc7/source/Documentation/arm/Booting#L160
[1] Documentation/arm/Booting
[2] Documentation/arm64/booting.txt


--
Sincerely,
Andrii Anisov.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.