[PATCH 3/8] add mem64_min/max control

[Yinghai Lu]

On Sat, Nov 17, 2012 at 12:25 AM, Eric W. Biederman
<ebiederm at xmission.com> wrote:
> Yinghai Lu <yinghai at kernel.org> writes:
>
>> On Fri, Nov 16, 2012 at 10:18 PM, Eric W. Biederman
>> <ebiederm at xmission.com> wrote:
>>> Yinghai Lu <yinghai at kernel.org> writes:
>>>
>>>> So could limit range for 4g above buffers.
>>>
>>> What is wrong with mem-min and mem-max?  At this point in the patchset
>>> it looks like you are introducing mem64-min and mem64-max as a hack to
>>> avoid fixing mem-min and mem-max properly.
>>
>> if we set mem-min high, some buffers for purgatory and real_mode can
>> not be allocated properly.
>
> Let's see.  For a 32bit kexec that is a fundamental limit, even if we
> are booting a 64bit kernel.
>
> For a 64bit kexec we have a 64bit purgatory so it should not be a
> problem to relocate it higher.
>
> Hmm.  I'm not certain about the real_mode bits.  Splitting out the 64bit
> bzImage loader from the 32bit bzImage loader should allow a lot of the
> legacy bits to be deleted.  Past that I think we simply down in the real
> of needing a command line pointer that is 64bit instead of the current
> 32bit one.  That we should be able to fix by fixing the boot protocol.
>
> Since the real mode bits when loading a 64bit kernel are just a
> parameter area there should be no fundamental reason for them to be
> below 4G.
>
> The code needs to default to loading the kernel in the non kdump case
> at the address it was compiled to run at.  But for the rest I really
> don't see why we can't load the kernel very high.

then for setup data (boot param) and command line, we have to set extra ident
mapping for them in kernel arch/x86/kernel/head_64.S

with my current patchset for kernel and kexec,  we only need to set
ident mapping
for [_text, _end) in kernel arch/x86/kernel/head_64.S

Yinghai