From: Alexander Graf <graf@amazon.com>
To: Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>
Cc: <linux-kernel@vger.kernel.org>,
<linux-trace-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
<devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<kexec@lists.infradead.org>, <linux-doc@vger.kernel.org>,
<x86@kernel.org>, Eric Biederman <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Rob Herring <robh+dt@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mark Rutland <mark.rutland@arm.com>,
"Tom Lendacky" <thomas.lendacky@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
James Gowans <jgowans@amazon.com>, <arnd@arndb.de>,
<pbonzini@redhat.com>, <madvenka@linux.microsoft.com>,
Anthony Yznaga <anthony.yznaga@oracle.com>,
Usama Arif <usama.arif@bytedance.com>,
David Woodhouse <dwmw@amazon.co.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH v2 04/17] kexec: Add KHO parsing support
Date: Mon, 15 Jan 2024 14:27:30 +0100 [thread overview]
Message-ID: <64047065-41a1-4235-b600-bf3530c76722@amazon.com> (raw)
In-Reply-To: <20240101033301.GA765@skinsburskii.>
On 01.01.24 04:33, Stanislav Kinsburskii wrote:
> On Fri, Dec 22, 2023 at 07:35:54PM +0000, Alexander Graf wrote:
>> +/**
>> + * kho_reserve_previous_mem - Adds all memory reservations into memblocks
>> + * and moves us out of the scratch only phase. Must be called after page tables
>> + * are initialized and memblock_allow_resize().
>> + */
>> +void __init kho_reserve_previous_mem(void)
>> +{
>> + void *mem_virt = __va(mem_phys);
>> + int off, err;
>> +
>> + if (!handover_phys || !mem_phys)
>> + return;
>> +
>> + /*
>> + * We reached here because we are running inside a working linear map
>> + * that allows us to resize memblocks dynamically. Use the chance and
>> + * populate the global fdt pointer
>> + */
>> + fdt = __va(handover_phys);
>> +
>> + off = fdt_path_offset(fdt, "/");
>> + if (off < 0) {
>> + fdt = NULL;
>> + return;
>> + }
>> +
>> + err = fdt_node_check_compatible(fdt, off, "kho-v1");
>> + if (err) {
>> + pr_warn("KHO has invalid compatible, disabling.");
> It looks like KHO preserved regions won't be reserved in this case.
> Should KHO DT state be destroyed here to prevent KHO memory regions
> reuse upon rollback?
Good catch. I'll set fdt to NULL in that case in v3.
>
>> +
>> +void __init kho_populate(phys_addr_t handover_dt_phys, phys_addr_t scratch_phys,
>> + u64 scratch_len, phys_addr_t mem_cache_phys,
>> + u64 mem_cache_len)
>> +{
>> + void *handover_dt;
>> +
>> + /* Determine the real size of the DT */
>> + handover_dt = early_memremap(handover_dt_phys, sizeof(struct fdt_header));
>> + if (!handover_dt) {
>> + pr_warn("setup: failed to memremap kexec FDT (0x%llx)\n", handover_dt_phys);
>> + return;
>> + }
>> +
>> + if (fdt_check_header(handover_dt)) {
>> + pr_warn("setup: kexec handover FDT is invalid (0x%llx)\n", handover_dt_phys);
>> + early_memunmap(handover_dt, PAGE_SIZE);
>> + return;
>> + }
>> +
>> + handover_len = fdt_totalsize(handover_dt);
>> + handover_phys = handover_dt_phys;
>> +
>> + /* Reserve the DT so we can still access it in late boot */
>> + memblock_reserve(handover_phys, handover_len);
>> +
>> + /* Reserve the mem cache so we can still access it later */
>> + memblock_reserve(mem_cache_phys, mem_cache_len);
>> +
>> + /*
>> + * We pass a safe contiguous block of memory to use for early boot purporses from
>> + * the previous kernel so that we can resize the memblock array as needed.
>> + */
>> + memblock_add(scratch_phys, scratch_len);
>> +
>> + if (WARN_ON(memblock_mark_scratch(scratch_phys, scratch_len))) {
>> + pr_err("Kexec failed to mark the scratch region. Disabling KHO.");
>> + handover_len = 0;
>> + handover_phys = 0;
> Same question here: doesn't all the KHO state gets invalid in case of any
> restoration error?
It does, which is what the error case here does, no? Or are you
referring to the fact that we're not unrolling the memblock
reservations? If we can't mark the scratch region, I'd rather leave
everything else alone. It means the scratch region is in a hole, which
should never happen.
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
next prev parent reply other threads:[~2024-01-15 13:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-22 19:35 [PATCH v2 00/17] kexec: Allow preservation of ftrace buffers Alexander Graf
2023-12-22 19:35 ` [PATCH v2 01/17] mm,memblock: Add support for scratch memory Alexander Graf
2023-12-22 19:35 ` [PATCH v2 02/17] memblock: Declare scratch memory as CMA Alexander Graf
2024-01-01 3:01 ` Stanislav Kinsburskii
2023-12-22 19:35 ` [PATCH v2 03/17] kexec: Add Kexec HandOver (KHO) generation helpers Alexander Graf
2023-12-22 19:35 ` [PATCH v2 04/17] kexec: Add KHO parsing support Alexander Graf
2024-01-01 3:33 ` Stanislav Kinsburskii
2024-01-15 13:27 ` Alexander Graf [this message]
2023-12-22 19:35 ` [PATCH v2 05/17] kexec: Add KHO support to kexec file loads Alexander Graf
2023-12-22 19:35 ` [PATCH v2 06/17] kexec: Add config option for KHO Alexander Graf
2023-12-22 19:35 ` [PATCH v2 07/17] kexec: Add documentation " Alexander Graf
2024-01-01 3:55 ` Stanislav Kinsburskii
2023-12-22 19:35 ` [PATCH v2 08/17] arm64: Add KHO support Alexander Graf
2023-12-22 19:35 ` [PATCH v2 09/17] x86: " Alexander Graf
2023-12-22 19:36 ` [PATCH v2 10/17] tracing: Initialize fields before registering Alexander Graf
2023-12-22 19:36 ` [PATCH v2 11/17] tracing: Introduce kho serialization Alexander Graf
2023-12-22 19:51 ` [PATCH v2 06/17] kexec: Add config option for KHO Alexander Graf
2023-12-22 19:51 ` [PATCH v2 07/17] kexec: Add documentation " Alexander Graf
2024-01-03 18:48 ` Rob Herring
2024-01-17 14:01 ` Alexander Graf
2024-01-17 16:54 ` Rob Herring
2024-01-17 17:00 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 08/17] arm64: Add KHO support Alexander Graf
2023-12-22 19:51 ` [PATCH v2 09/17] x86: " Alexander Graf
2023-12-22 19:51 ` [PATCH v2 10/17] tracing: Initialize fields before registering Alexander Graf
2023-12-22 19:51 ` [PATCH v2 11/17] tracing: Introduce kho serialization Alexander Graf
2023-12-22 19:51 ` [PATCH v2 12/17] tracing: Add kho serialization of trace buffers Alexander Graf
2023-12-22 19:51 ` [PATCH v2 13/17] tracing: Recover trace buffers from kexec handover Alexander Graf
2023-12-22 19:51 ` [PATCH v2 14/17] tracing: Add kho serialization of trace events Alexander Graf
2023-12-22 19:51 ` [PATCH v2 15/17] tracing: Recover trace events from kexec handover Alexander Graf
2023-12-22 19:51 ` [PATCH v2 16/17] tracing: Add config option for " Alexander Graf
2023-12-22 19:51 ` [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO Alexander Graf
2023-12-22 21:19 ` Rob Herring
2023-12-23 14:30 ` Krzysztof Kozlowski
2023-12-23 23:20 ` Alexander Graf
2023-12-24 8:58 ` Krzysztof Kozlowski
2024-01-02 14:53 ` Rob Herring
2024-01-02 15:20 ` Rob Herring
2024-01-17 13:56 ` Alexander Graf
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=64047065-41a1-4235-b600-bf3530c76722@amazon.com \
--to=graf@amazon.com \
--cc=akpm@linux-foundation.org \
--cc=anthony.yznaga@oracle.com \
--cc=arnd@arndb.de \
--cc=ashish.kalra@amd.com \
--cc=benh@kernel.crashing.org \
--cc=devicetree@vger.kernel.org \
--cc=dwmw@amazon.co.uk \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jgowans@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=mark.rutland@arm.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=robh+dt@kernel.org \
--cc=rostedt@goodmis.org \
--cc=skinsburskii@linux.microsoft.com \
--cc=thomas.lendacky@amd.com \
--cc=usama.arif@bytedance.com \
--cc=x86@kernel.org \
/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