Hi Akashi, On Thu, Nov 16, 2017 at 12:30 PM, AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx> wrote: > Bhupesh, > > On Wed, Nov 15, 2017 at 04:28:55PM +0530, Bhupesh Sharma wrote: >> > (snip) > >> # dmesg | grep -B 2 -i "ACPI reclaim" >> [ 0.000000] efi: 0x000039670000-0x0000396bffff [Runtime Code |RUN| | >> | | | | | |WB|WT|WC|UC] >> [ 0.000000] efi: 0x0000396c0000-0x00003970ffff [Boot Code | | | | >> | | | | |WB|WT|WC|UC] >> [ 0.000000] efi: 0x000039710000-0x00003975ffff [ACPI Reclaim Memory| >> | | | | | | | |WB|WT|WC|UC] >> >> 2. Now, I am not sure which kernel layer does the following changes (I am >> still trying to dig it out more), but I see that the 'Boot Code' and ACPI >> DSDT table regions are somehow merged into one memblock_region and appear as >> range '396c0000-3975ffff' in the '/proc/iomem' interface: >> >> # cat /proc/iomem | grep -A 2 -B 2 39 >> 00000000-3961ffff : System RAM >> 00080000-00b6ffff : Kernel code >> 00cb0000-0167ffff : Kernel data >> 0e800000-2e7fffff : Crash kernel >> 39620000-396bffff : reserved >> 396c0000-3975ffff : System RAM >> 39760000-3976ffff : reserved >> 39770000-397affff : reserved >> 397b0000-3989ffff : reserved >> 398a0000-398bffff : reserved >> 398c0000-39d3ffff : reserved >> 39d40000-3ed2ffff : System RAM >> > (snip) >> >> So, I am looking at what could be causing the 'Boot Code' and 'ACPI DSDT >> table' ranges to be merged into a single region at >> '0x0000396c0000-0x00003970ffff' which cannot be marked as RESERVED using >> 'memblock_is_reserved'. > > Simple:) The short answer is that memblock_add() does. > > The long answer: > First, please note that memblock maintains two type of regions list, > "memory" and "reserved". > > efi_init() > reserve_regions() > early_init_dt_add_memory_arch() > memblock_add() > memblock_add_range(memblock.memory) > > The memory regions described in efi.memmap are added to "memory" list > with all the neighboring regions being merged into ones, > in this case, "Runtime Code", "Boot Code", "ACPI Reclaim Memory" and others. > > The secret here is that "Runtime Code" is also marked with "NOMAP" flag in > reserve_regions(), which creates an isolated region since it now has > a different attribute. > Consequently only "Boot Code" and "ACPI Reclaim Memory" are > unified. > > Look at request_standard_resources(). It handles only "memory" list, > and doesn't care about whether any arbitrary part of memory is in > "reserved" list or not. Thanks for the pointers. Now I did some experiments and traversed the whole memblock path and I see how these two regions get merged into a single region which is later on recognized by 'request_standard_resources()' as a System RAM region rather than a RESERVED region. I recently reproduced this on a APM mustang with latest kernel as well when acpi is used to boot the machine, which makes me believe that this is a generic issue for arm64 machines with the 4.14 kernel and if they use acpi=force as the boot method. I am not sure, if a fix/or hack would be suitable for all underlying arm64 machines, but I am trying one on the arm64 machines I have to see if it fixes the issue. @Ard: Hi Ard, I think to create and test a clean solution for all arm64 boards it will take some time, in the meantime should we consider reverting the commit [1] to make sure that acpi enabled arm64 machines can boot with 4.14? Please let me know your opinion. [1] f56ab9a5b73ca2aee777ccdf2d355ae2dd31db5a (efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP) Thanks, Bhupesh -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
