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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 17 Dec 2018, Julien Grall wrote:
> 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.

Make sense. Add some of these thoughts to the commit message so that
this time we remember.


> > Cheers,
> > 
> > [1] Documentation/arm/Booting
> > [2] Documentation/arm64/booting.txt


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