On 23/08/2016:09:38:16 AM, AKASHI Takahiro wrote:

On Mon, Aug 22, 2016 at 02:47:30PM +0100, James Morse wrote:

quoted

On 22/08/16 02:29, AKASHI Takahiro wrote:

quoted

On Fri, Aug 19, 2016 at 04:52:17PM +0530, Pratyush Anand wrote:

quoted

It will help kexec-tools to prevent copying  of any unnecessary data. I
think, then you also need to change phys_offset calculation in kexec-tools. That
should be start of either of first "reserved" or "System RAM" block.

Good point, but I'm not sure this is always true.

quoted

Is there any system whose ACPI memory is *not* part of DRAM

From the spec, it looks like this is allowed.

What do you mean by 'DRAM'? Any ACPI region will be in the UEFI memory map, so
the question is what is its type and memory attributes?

Yes.

quoted

The UEFI spec[0] says ACPI regions can have a type of EfiACPIReclaimMemory or
EfiACPIMemoryNVS, the memory attributes aren't specified, so are chosen by the
firmware.

It is possible these regions have to be mapped non-cacheable, page 40 has a
couple of:

quoted

If no information about the table location exists in the UEFI memory map or

ACPI memory

quoted

descriptors, the table is assumed to be non-cached.

reserve_regions() in drivers/firmware/efi/arm-init.c will add any entry in the
memory map that has a 'WB' attribute to the memblock.memory list (via
early_init_dt_add_memory_arch()), it will also mark as no-map regions that have
this attribute and aren't in the is_reserve_region() list.

If these ACPI regions have the 'WB' attribute, we add them as memory and mark
them nomap. These show up as either a hole, or 'reserved' in /proc/iomem.
If they don't have the 'WB' attribute, then then they are left out of memblock
and aren't part of DRAM, I don't think these will show up in /proc/iomem at all.

Let's say,
0x1000-0x1fff: reserved (SRAM for UEFI, WB)
0x80000000-0xffffffff: System RAM (DRAM)

May be slightly more complicated:
0x80000000-0x80001fff: System RAM (DRAM) for UEFI, WB
0x80002000-0xffffffff: System RAM (DRAM)

Kernel will have phys_offset 0x80000000, however kexec-tools will calculate it
as 0x80002000.

If, as Pratyush suggested, "reserved" resources are added to phys_offset
calculation, the kernel linear mapping area starts at PAGE_OFFSET, but
there is no actual mapping around PAGE_OFFSET.
It won't hurt anything, but looks funny.
So we'd better not include "reserved" in phys_offset calculation anyway.
        -> Pratyush

My only concern is that, then we will have different values of phys_offset in
kernel and kexec-tools, which might lead to further confusion.

~Pratyush