Re: [PATCH 3/8] add mem64_min/max control

Yinghai Lu
2012-11-17T20:04:35Z

On Sat, Nov 17, 2012 at 12:25 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Yinghai Lu <yinghai@kernel.org> writes:
>
>> On Fri, Nov 16, 2012 at 10:18 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> Yinghai Lu <yinghai@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