[PATCH 18/19] arm64: kdump: update a kernel doc

On 01/20/16 at 05:01pm, AKASHI Takahiro wrote:

On 01/20/2016 04:00 PM, Dave Young wrote:

quoted

quoted

quoted

So I'm not still sure about what are advantages of a property under /chosen
over "memmap=" kernel parameter.
Both are simple and can have the same effect with minimizing changes to dtb.
(But if, in the latter case, we have to provide *all* the memory-related information
through "memmap=" parameters, it would be much complicated.)

Maybe I did not say it clearly, I prefer kexec syscall/tool to modifiy dtb
or uefi-memmap so that we do not need any extra kernel cmdline.

Yes, I understand.
But on arm64, kexec-tools can generate a "memmap=" parameter for crash kernel's
memory region without any user's interaction.
(please note that this parameter eventually goes into dtb's cmdline property in
/chosen.)

In this sense, it is no different from an extra property under /chosen
as kexec-tools can also add it to dtb passed to the crash dump kernel.

(See what I mean?)

I think I understand your points, what I would prefer is not an extra property
but modifying uefi memmap or recreating memory nodes for !EFI to be used in kdump kernel.

quoted

quoted

For x86 we would like to drop the memmap= usage in kexec-tools

I didn't know that :)

quoted

quoted

but we can not
do that for a compatibility problem about calgary iommu. So that currently
kexec-tools supports both recreating E820 maps and passing memmap=.

We should think it carefully because it will be hard to remove once we support it.

Absolutely.

quoted

quoted

IMO handling it in code is better than using an external interface.

Also seems semantic of memmap=exactmap is different than current use in the implementation
exactmap means we need pass each range seperately including reserved, acpi and other types
We can not reuse ranges in uefi memmap for other than usable memory.

If necessary, we may use a different name, say, "usablememmap=" for arm64
or just extend "mem=" semantics (allowing XX at YY format) to avoid any confusion.

For either of above what is the 1st kernel behavior with these params?

Thanks,
-Takahiro AKASHI

quoted

It will also have the cmdline array size issue.k

Thanks
Dave