[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 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |