On Mon, May 2, 2016 at 3:40 PM, Russell King - ARM Linux
[off-list ref] wrote:

On Mon, May 02, 2016 at 01:04:28PM +0530, Pratyush Anand wrote:

quoted

On Sat, Apr 30, 2016 at 1:50 PM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Sat, Apr 30, 2016 at 08:57:34AM +0530, Pratyush Anand wrote:

quoted

On Fri, Apr 29, 2016 at 11:30 PM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Fri, Apr 29, 2016 at 08:26:00PM +0530, Pratyush Anand wrote:

quoted

Hi Russell,

On Thu, Apr 28, 2016 at 2:58 PM, Russell King
[off-list ref] wrote:

quoted

Advertise the location of bootable RAM to kexec-tools.  kexec needs to
know where it can place the kernel in RAM, and so be executable when
the system needs to jump into it.

Advertise these areas in /proc/iomem with a "System RAM (boot alias)"
tag.

Signed-off-by: Russell King <redacted>

Can you please also share git tree path of corresponding kexec-tools changes?

Could it be a better idea (if things in user space become simpler)
that in stead of patch 5 and 6, we pass arch_phys_to_idmap_offset to
user space, and then user space manipulates existing "Crash kernel"
and "System RAM" resources.

Given that it's only _one_ platform right now, I don't think that
additional complexity is worth it.  It means that we have to invent

Probably, I could not communicate it well.  I was not trying  to have
*additional* complexity. Wanted to see if things could be simpler
rather. So this is what my understanding was:
-- We create one patch to pass arch_phys_to_idmap_offset to user space
(say in /sys/kernel/bootmem_idmap_offset)
-- We do not use patch 5,6,11 and 12 of this series. Probably few more
content of the series will go away.

Patches 11 and 12 don't go away with what you're suggesting.  Patches
11 and 12 are necessary to allow the boot-view addresses to be passed
into the kernel through kexec, and to allow kexec to find appropriate
memory resources.

But once we would have manipulated "start" and "end" of "Crash Kernel"
and "System RAM" resources in user space using
/sys/kernel/bootmem_idmap_offset , then kernel through kexec system
call would have already receive boot-view addresses, no?

Correct, but that's still a problem for all the reasons I gave in the
email to which you replied to.

I'm not sure where the misunderstanding is.

No, no..there is no misunderstanding. I agreed to your implementation
because that will work for generic cases and for me complete series is
OK.

I just wanted to clarify my understanding, and so was the last argument.

Let me repeat: even if we do what you're suggesting, patches 11 and 12
do *not* go away.  I've explained in detail why each of the changes are
necessary (which you have cut from your reply.)

Again, it is just for clarifying myself.
I cut the reply because I understood that in patch 11 and 12, you
convert addresses passed by kexec tools from run time view to boot
view using different helpers like phys_to_boot_phys(). So, had kexec
system call passed boot view addresses, we would have not needed 11
and 12. This is what I wanted to clarify.

In other words: exporting this offset via
/sys/kernel/bootmem_idmap_offset is technically inferior to the solution
I have come up with here, and it saves very little complexity and code.

I still have opinion that code will probably be more simple and reduce
significantly, however solution will siege to work the moment
idmap_offset is not a simple additive value.

Therefore, I am OK with your implementation.

~Pratyush