Re: [PATCH V2] RISC-V: Add support for riscv kexec/kdump on kexec-tools
在 2022/10/26 上午10:13, Xianting Tian 写道:
Hi Simon
thanks for the comments
在 2022/10/21 下午11:27, Simon Horman 写道:
On Thu, Oct 20, 2022 at 11:15:48AM +0800, Xianting Tian wrote:
From: Nick Kossifidis
This patch adds support for loading the ELF kernel image. It parses
the current/provided device tree to determine the system's memory
layout, and /proc/iomem for the various kernel segments.
This patch was firstly developed by Nick Kossifidis, and two fixes (
1: fail to find free memory area for dtb load when using initrd
image,
lists.infradead.org/pipermail/linux-riscv/2022-August/018398.html;
2: fix memory range size calculation,
kexec/arch/riscv/crashdump-riscv.c:line 85
) are contributed by Yixun Lan, Xianting Tian.
Tested on Qemu's rv64 virt machine and SoC of T-Head RISC-V Xuantie
910 CPU.
Hi,
thanks for some patch.
Some minor feedback follows.
Separately, I'll post a patch to add RISC-V builds to the github
workflow. If you could include that in V3 I'd be most grateful.
Tested-by: Yixun Lan
Co-developed-by: Xianting Tian
Co-developed-by: Yixun Lan
Signed-off-by: Nick Kossifidis
...
+ ret = mem_regions_alloc_and_add(mem_ranges, start,
+ end - start, type);
mem_regions_alloc_and_add isn't always available.
f.e. on mips this causes a build failure.
Ref:
https://github.com/horms/kexec-tools/actions/runs/3298491143/jobs/5440677595
As you know, mem_regions_sort, mem_regions_alloc_and_add are the
common funtions,
The build error of mips is caused by this riscv patch?
kexec/mem_regions.c:void mem_regions_sort(struct memory_ranges *ranges)
kexec/mem_regions.h:void mem_regions_sort(struct memory_ranges *ranges);
kexec/mem_regions.c:int mem_regions_alloc_and_add(struct memory_ranges
*ranges,
kexec/mem_regions.h:int mem_regions_alloc_and_add(struct memory_ranges
*ranges,
...
+int dtb_get_memory_ranges(char *dtb, struct memory_ranges
*mem_ranges, struct memory_ranges *extra_ranges)
+{
...
+ mem_regions_sort(mem_ranges);
Likewise, mem_regions_sort isn't always available.
f.e. on mips this causes a build failure.
...
diff --git a/purgatory/arch/riscv/Makefile
b/purgatory/arch/riscv/Makefile
new file mode 100644
index 000..8bded71
--- /dev/null
+++ b/purgatory/arch/riscv/Makefile
@@ -0,0 +1,7 @@
+#
+# Purgatory riscv
+#
+
+riscv_PURGATORY_SRCS =
+
+dist += purgatory/arch/sh/Makefile $(riscv_PURGATORY_SRCS)
s/sh/riscv/
Else the distribution tarball won't include this Makefile
You can exercise this using:
make distcheck DISTCHECK_CONFIGURE_FLAGS="--host=riscv64-linux-gnu"
thanks, I will fix this.
the fix is in my personal gitee
https://gitee.com/xianting-tian/kexec-tools/commits/master
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V2] RISC-V: Add support for riscv kexec/kdump on kexec-tools
Hi Simon
thanks for the comments
在 2022/10/21 下午11:27, Simon Horman 写道:
On Thu, Oct 20, 2022 at 11:15:48AM +0800, Xianting Tian wrote:
From: Nick Kossifidis
This patch adds support for loading the ELF kernel image. It parses
the current/provided device tree to determine the system's memory
layout, and /proc/iomem for the various kernel segments.
This patch was firstly developed by Nick Kossifidis, and two fixes (
1: fail to find free memory area for dtb load when using initrd image,
lists.infradead.org/pipermail/linux-riscv/2022-August/018398.html;
2: fix memory range size calculation,
kexec/arch/riscv/crashdump-riscv.c:line 85
) are contributed by Yixun Lan, Xianting Tian.
Tested on Qemu's rv64 virt machine and SoC of T-Head RISC-V Xuantie 910 CPU.
Hi,
thanks for some patch.
Some minor feedback follows.
Separately, I'll post a patch to add RISC-V builds to the github
workflow. If you could include that in V3 I'd be most grateful.
Tested-by: Yixun Lan
Co-developed-by: Xianting Tian
Co-developed-by: Yixun Lan
Signed-off-by: Nick Kossifidis
...
+ ret = mem_regions_alloc_and_add(mem_ranges, start,
+ end - start, type);
mem_regions_alloc_and_add isn't always available.
f.e. on mips this causes a build failure.
Ref:
https://github.com/horms/kexec-tools/actions/runs/3298491143/jobs/5440677595
As you know, mem_regions_sort, mem_regions_alloc_and_add are the common
funtions,
The build error of mips is caused by this riscv patch?
kexec/mem_regions.c:void mem_regions_sort(struct memory_ranges *ranges)
kexec/mem_regions.h:void mem_regions_sort(struct memory_ranges *ranges);
kexec/mem_regions.c:int mem_regions_alloc_and_add(struct memory_ranges
*ranges,
kexec/mem_regions.h:int mem_regions_alloc_and_add(struct memory_ranges
*ranges,
...
+int dtb_get_memory_ranges(char *dtb, struct memory_ranges *mem_ranges, struct
memory_ranges *extra_ranges)
+{
...
+ mem_regions_sort(mem_ranges);
Likewise, mem_regions_sort isn't always available.
f.e. on mips this causes a build failure.
...
diff --git a/purgatory/arch/riscv/Makefile b/purgatory/arch/riscv/Makefile
new file mode 100644
index 000..8bded71
--- /dev/null
+++ b/purgatory/arch/riscv/Makefile
@@ -0,0 +1,7 @@
+#
+# Purgatory riscv
+#
+
+riscv_PURGATORY_SRCS =
+
+dist += purgatory/arch/sh/Makefile $(riscv_PURGATORY_SRCS)
s/sh/riscv/
Else the distribution tarball won't include this Makefile
You can exercise this using:
make distcheck DISTCHECK_CONFIGURE_FLAGS="--host=riscv64-linux-gnu"
thanks, I will fix this.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On Wed, Oct 12, 2022 at 11:20:59AM -0500, Eric DeVolder wrote: > I once had CONFIG_CRASH_HOTPLUG, but you disagreed. > > https://lore.kernel.org/lkml/ylgot+ludql+g%2...@zn.tnic/ > > From there I simply went with > > #if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_MEMORY_HOTPLUG) > > which route do you prefer? If you do a single Kconfig item which depends on those two, it probably is cleaner this way. And if the max memory ranges are hardcoded you don't need the other prompt asking the user something she most likely doesn't know how to answer properly. That is, unless you wanna have that crash hotplug built in all the time. Because CONFIG_HOTPLUG_CPU is pretty much always enabled so you might just as well add the crash hotplug support unconditionally, without any Kconfig ifdeffery whatsoever except CONFIG_MEMORY_HOTPLUG as that is special and not present on the majority of hardware. But on a plain simple laptop or workstation which has CPU hotplug, would it make sense for the crash ranges to get updated too when CPUs are offlined? If so, I think you want this code present there too, without a Kconfig item. If this is server-only anyway, then a single Kconfig item sounds like not such a bad idea. I hope that makes some sense. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v12 7/7] x86/crash: Add x86 crash hotplug support
On Thu, Oct 13, 2022 at 10:57:28AM +0800, Baoquan He wrote: > The concern to range number mainly is on Virt guest systems. And why would virt emulate 1K hotpluggable DIMM slots and not emulate a real machine? > On baremetal system, basically only very high end server support > memory hotplug. I ever visited customer's lab and saw one server, > it owns 8 slots, on each slot a box containing about 20 cpus and 2T > memory at most can be plugged in at one time. So people won't make too > many slots for hotplugging since it's too expensive. There you have it - the persuading argument. > I checked user space kexec code, the maximum memory range number is > honored to x86_64 because of a HPE SGI system. After that, nobody > complains about it. Please see below user space kexec-tools commit in > https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git > > The memory ranges may be not all made by different DIMM slots, could be > firmware reservatoin, e.g efi/BIOS diggged out physical memory, ^ I don't know what that means. If it is firmware crap, you want to exclude that from kdump anyway. > Now CONFIG_NR_CPUS has the maximum number as 8192. And user space > kexec-tools has maximum memory range number as 2048. We can take > the current 8192 + 2048 = 10K as default value conservatively. Or > take 8192 + 2048 * 2 = 12K which has two times of maximum memory range > bumber in kexec-tools. What do you think? I still think that we should stick to reality and support what is possible not what is potentially and theoretically there. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
