From: Alexander Graf <graf@amazon.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: <kexec@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
<nh-open-source@amazon.com>, Baoquan He <bhe@redhat.com>,
Zhongkun He <hezhongkun.hzk@bytedance.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v5] kexec: Enable CMA based contiguous allocation
Date: Tue, 22 Jul 2025 00:01:25 +0200 [thread overview]
Message-ID: <07b21458-832f-4b15-9bc8-43f21f902e34@amazon.com> (raw)
In-Reply-To: <CA+CK2bBhUdEjD=-gM3=D6mKBYctbXh74_hq-bMf1fa8mfS2Edg@mail.gmail.com>
On 10.06.25 13:31, Pasha Tatashin wrote:
> On Tue, Jun 10, 2025 at 4:53 AM Alexander Graf <graf@amazon.com> wrote:
>> When booting a new kernel with kexec_file, the kernel picks a target
>> location that the kernel should live at, then allocates random pages,
>> checks whether any of those patches magically happens to coincide with
>> a target address range and if so, uses them for that range.
>>
>> For every page allocated this way, it then creates a page list that the
>> relocation code - code that executes while all CPUs are off and we are
>> just about to jump into the new kernel - copies to their final memory
>> location. We can not put them there before, because chances are pretty
>> good that at least some page in the target range is already in use by
>> the currently running Linux environment. Copying is happening from a
>> single CPU at RAM rate, which takes around 4-50 ms per 100 MiB.
>>
>> All of this is inefficient and error prone.
>>
>> To successfully kexec, we need to quiesce all devices of the outgoing
>> kernel so they don't scribble over the new kernel's memory. We have seen
>> cases where that does not happen properly (*cough* GIC *cough*) and hence
>> the new kernel was corrupted. This started a month long journey to root
>> cause failing kexecs to eventually see memory corruption, because the new
>> kernel was corrupted severely enough that it could not emit output to
>> tell us about the fact that it was corrupted. By allocating memory for the
>> next kernel from a memory range that is guaranteed scribbling free, we can
>> boot the next kernel up to a point where it is at least able to detect
>> corruption and maybe even stop it before it becomes severe. This increases
>> the chance for successful kexecs.
>>
>> Since kexec got introduced, Linux has gained the CMA framework which
>> can perform physically contiguous memory mappings, while keeping that
>> memory available for movable memory when it is not needed for contiguous
>> allocations. The default CMA allocator is for DMA allocations.
>>
>> This patch adds logic to the kexec file loader to attempt to place the
>> target payload at a location allocated from CMA. If successful, it uses
>> that memory range directly instead of creating copy instructions during
>> the hot phase. To ensure that there is a safety net in case anything goes
>> wrong with the CMA allocation, it also adds a flag for user space to force
>> disable CMA allocations.
>>
>> Using CMA allocations has two advantages:
>>
>> 1) Faster by 4-50 ms per 100 MiB. There is no more need to copy in the
>> hot phase.
>> 2) More robust. Even if by accident some page is still in use for DMA,
>> the new kernel image will be safe from that access because it resides
>> in a memory region that is considered allocated in the old kernel and
>> has a chance to reinitialize that component.
>>
>> Signed-off-by: Alexander Graf <graf@amazon.com>
>> Acked-by: Baoquan He <bhe@redhat.com>
> Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
Andrew, I don't see this patch in linus/master. Is it still in your
queue? :)
Alex
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
next prev parent reply other threads:[~2025-07-21 22:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 8:53 [PATCH v5] kexec: Enable CMA based contiguous allocation Alexander Graf
2025-06-10 11:31 ` Pasha Tatashin
2025-07-21 22:01 ` Alexander Graf [this message]
2025-07-21 22:33 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=07b21458-832f-4b15-9bc8-43f21f902e34@amazon.com \
--to=graf@amazon.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=hezhongkun.hzk@bytedance.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nh-open-source@amazon.com \
--cc=pasha.tatashin@soleen.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox