Hey Jason,
On 27.01.25 05:15, Jason Gunthorpe wrote:
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???
I agree with the simplifications you're proposing; not using the
purgatory would be a great property to have.
The reason why KHO doesn't do it yet is that I wanted to keep it simple
from the other end. The big problem with going A/B is that if done the
simple way, you only map B as MOVABLE while running in A. That means A
could accidentally allocate persistent memory from A's memory region.
When A then switches to B, B can no longer make all of A MOVABLE.
So we need to ensure that *both* regions are MOVABLE, and the system is
always fully aware of both.
Alex
