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
