On Mon, Feb 24, 2025 at 02:50:34AM +0000, Wei Yang wrote: > On Thu, Feb 06, 2025 at 03:27:43PM +0200, Mike Rapoport wrote: > >From: Alexander Graf <graf@xxxxxxxxxx> > > > >With KHO (Kexec HandOver), we need a way to ensure that the new kernel > >does not allocate memory on top of any memory regions that the previous > >kernel was handing over. But to know where those are, we need to include > >them in the memblock.reserved array which may not be big enough to hold > >all ranges that need to be persisted across kexec. To resize the array, > >we need to allocate memory. That brings us into a catch 22 situation. > > > >The solution to that is limit memblock allocations to the scratch regions: > >safe regions to operate in the case when there is memory that should remain > >intact across kexec. > > > >KHO provides several "scratch regions" as part of its metadata. These > >scratch regions are contiguous memory blocks that known not to contain any > >memory that should be persisted across kexec. These regions should be large > >enough to accommodate all memblock allocations done by the kexeced kernel. > > > >We introduce a new memblock_set_scratch_only() function that allows KHO to > > memblock_set_kho_scratch_only? > > >indicate that any memblock allocation must happen from the scratch regions. > > > >Later, we may want to perform another KHO kexec. For that, we reuse the > >same scratch regions. To ensure that no eventually handed over data gets > >allocated inside a scratch region, we flip the semantics of the scratch > >region with memblock_clear_scratch_only(): After that call, no allocations > > memblock_clear_kho_scratch_only? Right, I missed those in the commit message. > >may happen from scratch memblock regions. We will lift that restriction > >in the next patch. > > > > -- > Wei Yang > Help you, Help me -- Sincerely yours, Mike.
