On Sun, Jan 26, 2025 at 04:21:05PM -0800, Alexander Graf wrote: > Yes, this is easier said than done. In the user space driven kexec path, > user space is in control of memory locations. At least after the first kexec > iteration, these locations will overlap with the existing Linux runtime > environment, because both lie in the scratch region. Only the purgatory > moves everything to where it should be. This just doesn't seem ideal to me.. It makes sense for old fashioned kexec, but if you are committed to KHO start earlier. I would imagine a system that wants to do KHO to have A/B chunks of memory that are used to boot up the kernel, and the running kernel keeps the successor kernel's chunk entirely as ZONE_MOVABLE. When kexec time comes the running kernel evacuates the successor chunk, and the new kernel gets one of two reliable linear mappings to work with. No complex purgatory, no copying, its simple. The next kernel then makes the prior kernel's chunk ZONE_MOVABLE and the cycle repeats. Why make it so complicated by using overlapping memory??? Jason
