Re: [LSF/MM/BPF TOPIC] memory persistence over kexec

[Alexander Graf <graf@amazon.com>]

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