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. > mem64-min and mem64-max are used to limit range for buffer that could > stay above 4g. > like limit them one range belong to one node only. Having the limits makes sense. Requring anything other than the low 1MB magic below 4G seems wrong if we are going to go all of the way and push the boot protocol as far as we can. Eric
