From: Youling Tang <youling.tang@linux.dev>
To: Qiang Ma <maqianga@uniontech.com>
Cc: Huacai Chen <chenhuacai@kernel.org>,
kernel@xen0n.name, loongarch@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] LoongArch: kexec_file: print out debugging message if required
Date: Fri, 24 Oct 2025 17:27:57 +0800 [thread overview]
Message-ID: <1b865cb8-5262-432f-a090-c0bd9064dae2@linux.dev> (raw)
In-Reply-To: <4FED52AA3D608E61+96b50af7-cc24-40b0-a723-3b01f8428831@uniontech.com>
On 10/24/25 17:04, Qiang Ma wrote:
>
> 在 2025/10/24 15:26, Youling Tang 写道:
>> On 10/24/25 15:04, Huacai Chen wrote:
>>
>>> Hi, Youling,
>>>
>>> What do you think about this?
>>>
>>> Huacai
>>>
>>> On Tue, Oct 21, 2025 at 5:12 PM Qiang Ma <maqianga@uniontech.com>
>>> wrote:
>>>> When specifying '-d' for kexec_file_load interface, loaded locations
>>>> of kernel/initrd/cmdline etc can be printed out to help debug.
>>
>> Although kexec_image_info() could be considered for removal in the
>> case of kexec_file,
>> in the context of kexec_load, when using the -d parameter of
>> kexec-tools, although the
>> userspace program outputs extensive debugging information, it is
>> recommended to retain
>> this information during the debugging phase to verify the accuracy of
>> data transmission
>> after it is passed into the kernel.
>>
> In the system call kexec_file_load(), after machine_kexec_prepare() is
> executed,
>
> there will be the same print information as the kexec_image_info(),
> and no modifications
>
> were made to the printed information during this period. Therefore, it
> can also verify
>
> the accuracy of the data, right?
If only for kexec_file_load, we can directly remove kexec_image_info().
But for kexec_load, I suggest keeping it.
Youling.
>
>
> Thanks,
>
> Qiang.
>
>
>> Thanks,
>> Youling.
>>>>
>>>> Commit eb7622d908a0 ("kexec_file, riscv: print out debugging message
>>>> if required") fixes the same issue on RISC-V.
>>>>
>>>> So, remove kexec_image_info() because the content has been printed
>>>> out in generic code.
>>>>
>>>> And on Loongson-3A5000, the printed messages look like below:
>>>>
>>>> [ 288.667939] kexec_file: kernel: 00000000d9aad283 kernel_size:
>>>> 0x2e77f30
>>>> [ 288.668414] kexec_file(EFI): No LoongArch PE image header.
>>>> [ 288.703104] kexec_file: Loaded initrd at 0x80000000
>>>> bufsz=0x1637cd0 memsz=0x1638000
>>>> [ 288.703674] kexec_file(ELF): Loaded kernel at 0x9c20000
>>>> bufsz=0x27f1800 memsz=0x2950000
>>>> [ 288.704092] kexec_file: nr_segments = 2
>>>> [ 288.704277] kexec_file: segment[0]: buf=0x00000000cc3e6c33
>>>> bufsz=0x27f1800 mem=0x9c20000 memsz=0x2950000
>>>> [ 288.741213] kexec_file: segment[1]: buf=0x00000000bb75a541
>>>> bufsz=0x1637cd0 mem=0x80000000 memsz=0x1638000
>>>> [ 288.757182] kexec_file: kexec_file_load: type:0, start:0xb15d000
>>>> head:0x18db60002 flags:0x8
>>>>
>>>> Signed-off-by: Qiang Ma <maqianga@uniontech.com>
>>>> ---
>>>> arch/loongarch/kernel/machine_kexec.c | 22 ----------------------
>>>> 1 file changed, 22 deletions(-)
>>>>
>>>> diff --git a/arch/loongarch/kernel/machine_kexec.c
>>>> b/arch/loongarch/kernel/machine_kexec.c
>>>> index e4b2bbc47e62..2d64b7c81e5e 100644
>>>> --- a/arch/loongarch/kernel/machine_kexec.c
>>>> +++ b/arch/loongarch/kernel/machine_kexec.c
>>>> @@ -39,34 +39,12 @@ static unsigned long systable_ptr;
>>>> static unsigned long start_addr;
>>>> static unsigned long first_ind_entry;
>>>>
>>>> -static void kexec_image_info(const struct kimage *kimage)
>>>> -{
>>>> - unsigned long i;
>>>> -
>>>> - pr_debug("kexec kimage info:\n");
>>>> - pr_debug("\ttype: %d\n", kimage->type);
>>>> - pr_debug("\tstart: %lx\n", kimage->start);
>>>> - pr_debug("\thead: %lx\n", kimage->head);
>>>> - pr_debug("\tnr_segments: %lu\n", kimage->nr_segments);
>>>> -
>>>> - for (i = 0; i < kimage->nr_segments; i++) {
>>>> - pr_debug("\t segment[%lu]: %016lx - %016lx", i,
>>>> - kimage->segment[i].mem,
>>>> - kimage->segment[i].mem +
>>>> kimage->segment[i].memsz);
>>>> - pr_debug("\t\t0x%lx bytes, %lu pages\n",
>>>> - (unsigned long)kimage->segment[i].memsz,
>>>> - (unsigned long)kimage->segment[i].memsz /
>>>> PAGE_SIZE);
>>>> - }
>>>> -}
>>>> -
>>>> int machine_kexec_prepare(struct kimage *kimage)
>>>> {
>>>> int i;
>>>> char *bootloader = "kexec";
>>>> void *cmdline_ptr = (void *)KEXEC_CMDLINE_ADDR;
>>>>
>>>> - kexec_image_info(kimage);
>>>> -
>>>> kimage->arch.efi_boot = fw_arg0;
>>>> kimage->arch.systable_ptr = fw_arg2;
>>>>
>>>> --
>>>> 2.20.1
>>>>
>>
>
next prev parent reply other threads:[~2025-10-24 9:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 9:11 [PATCH] LoongArch: kexec_file: print out debugging message if required Qiang Ma
2025-10-24 7:04 ` Huacai Chen
2025-10-24 7:26 ` Youling Tang
2025-10-24 9:04 ` Qiang Ma
2025-10-24 9:27 ` Youling Tang [this message]
2025-10-24 13:01 ` Qiang Ma
2025-11-10 9:24 ` Huacai Chen
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=1b865cb8-5262-432f-a090-c0bd9064dae2@linux.dev \
--to=youling.tang@linux.dev \
--cc=chenhuacai@kernel.org \
--cc=kernel@xen0n.name \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=maqianga@uniontech.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