[..]> ==============================================================> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig> index 880fcb6..999ea82 100644> --- a/arch/x86/Kconfig> +++ b/arch/x86/Kconfig> @@ -1548,8 +1548,8 @@ config PHYSICAL_START> If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then> bzImage will decompress itself to above physical address and> run from there. Otherwise, bzImage will run from the address where> - it has been loaded by the boot loader and will ignore above physical> - address.> + it has been loaded by the boot loader, using the above physical> + address as a lower bound.> > In normal kdump cases one does not have to set/change this option> as now bzImage can be compiled as a completely relocatable image> @@ -1595,7 +1595,31 @@ config RELOCATABLE> > Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address> it has been loaded at and the compile time physical address> - (CONFIG_PHYSICAL_START) is ignored.> + (CONFIG_PHYSICAL_START) is solely used as a lower bound.> +

This does not sound too good. Overloading the definition of PHYSICAL_STARTwith minimum address. The very definition of relocatable kernel is thatit should be able to run from the physical address it has been loadedat (subjected to alignment constraints).

So I don't think overloading CONFIG_PHYSICAL_START definition is a goodidea. In fact there is no reason that why kdump kernels should not runand boot below 16MB. So limiting those kernels to not load and runbelow 16MB is does not sound like good option to me.

Also randomization of kernel load address at run time will probably havesome issues with crashkernel=X@Y address syntax. So far user knew whataddress first kernel is booting from and user could speicy where to reserve memory. Now it might happen that user specified some memoryto reserve and kernel decided to occupy that space resulting in failedmemory reservation for crash kernel.