should kernel image destination address be picked up by kernel itself?

[Eric W. Biederman]

"Ming Lei" <mlei at Brocade.COM> writes:

> Eric,
>
>>>"Ming Lei" <mlei at Brocade.COM> writes:
>>> As I understand the code, current destination address is picked up by
>>> either the user(elf image) or kexec-tools. It is not automatic, can
> we
>>> let linux kernel choose the address instead? It is automatic and no
> way
>>> to wipe out something important.
>
>>I don't follow.  The basic model of kexec is:
>>2)- All of the policy decisions are made in user space (such as where
> to
>>  execute from)
>
>>3)- standalone executables are loaded into an address space where
>>  physical address and virtual address are the same.
>
>>4)- Sophisticated page swapping happens in the kernel where
>>  sys_kexec_load was called so that any valid address on the machine
>>  is available to the standalone executable.
>
>>What problem do you see in that model?
>>Why is it a problem for you?
>
>>Eric
>
> I generally agree on 2). However, to choose where to copy the kimage
> segments, should the kernel be the one to make this decision so to avoid
> export memory map to user space, since the kernel knows where are all
> the free memory. This doesn't complicate the kernel code and meanwhile
> simplify the user space code and reduce the requirement for different
> platforms(so other platforms doesn't need to export kernel memory map).

Nothing needs to export the kernel memory map.  What is exported is
the kernels knowledge of where physical memory is.  Where the running
kernel is irrelevant.

I am fairly certain openfirmware provides that interface today.
And even outside of the context of kexec we need that information to
pass to the newly loaded kernel so it knows what memory it can use.

> I think 3) and 4) is more the requirements from x86. On ppc32 I don't
> see the need for it. So 3) and 4) should be in platform specifics.

3 is the design and if ppc32 doesn't do that it is broken.

4 also is a general requirement.  It is rare an architecture will have
a 1M+ range of physically contiguous pages.

Dealing with physical addresses in early boot and not having to get
sophisticated and play page table games is very desirable.

Eric