* [PATCH v1 1/3] crashdump/x86: dump any kind of "System RAM"
2021-03-23 10:01 [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM David Hildenbrand
@ 2021-03-23 10:01 ` David Hildenbrand
2021-03-31 15:47 ` Dave Hansen
2021-03-23 10:01 ` [PATCH v1 2/3] crashdump/x86: iterate only over actual crash memory ranges David Hildenbrand
` (2 subsequent siblings)
3 siblings, 1 reply; 8+ messages in thread
From: David Hildenbrand @ 2021-03-23 10:01 UTC (permalink / raw)
To: kexec
Cc: David Hildenbrand, Dan Williams, Dave Hansen, Baoquan He,
Simon Horman
Traditionally, we had "System RAM" only on the top level of in the
kernel resource tree (-> /proc/iomem). Nowadays, we can also have
"System RAM" on lower levels of the tree -- driver-managed device memory
that is always detected and added via drivers. Current examples are
memory added via dax/kmem -- ("System RAM (kmem)") and virtio-mem ("System
RAM (virtio_mem)"). Note that in some kernel versions "System RAM
(kmem)" was exposed as "System RAM", but similarly, on lower levels of
the resource tree.
Let's add anything that contains "System RAM" to the elf core header, so
it will be dumped for kexec_load(). Handling kexec_file_load() in the
kernel is similarly getting fixed [1].
Loading a kdump kernel via "kexec -p -c" ... will result in the kdump
kernel to also dump dax/kmem and virtio-mem added System RAM now.
Note: We only want to dump this memory, we don't want to add this memory to
the memmap of an ordinary kexec'ed kernel ("fast system reboot").
[1] https://lkml.kernel.org/r/20210322160200.19633-1-david@redhat.com
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
kexec/arch/i386/crashdump-x86.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index d5b5b68..a301ac8 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -271,8 +271,14 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
str = line + consumed;
dbgprintf("%016llx-%016llx : %s",
start, end, str);
- /* Only Dumping memory of type System RAM. */
- if (memcmp(str, "System RAM\n", 11) == 0) {
+ /*
+ * We want to dump any System RAM -- memory regions currently
+ * used by the kernel. In the usual case, this is "System RAM"
+ * on the top level. However, we can also have "System RAM
+ * (virtio_mem)" below virtio devices or "System RAM (kmem)"
+ * below "Persistent Memory".
+ */
+ if (strstr(str, "System RAM")) {
type = RANGE_RAM;
} else if (memcmp(str, "ACPI Tables\n", 12) == 0) {
/*
--
2.29.2
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH v1 1/3] crashdump/x86: dump any kind of "System RAM"
2021-03-23 10:01 ` [PATCH v1 1/3] crashdump/x86: dump any kind of "System RAM" David Hildenbrand
@ 2021-03-31 15:47 ` Dave Hansen
0 siblings, 0 replies; 8+ messages in thread
From: Dave Hansen @ 2021-03-31 15:47 UTC (permalink / raw)
To: David Hildenbrand, kexec
Cc: Dan Williams, Dave Hansen, Baoquan He, Simon Horman
On 3/23/21 3:01 AM, David Hildenbrand wrote:
> Traditionally, we had "System RAM" only on the top level of in the
> kernel resource tree (-> /proc/iomem). Nowadays, we can also have
> "System RAM" on lower levels of the tree -- driver-managed device memory
> that is always detected and added via drivers. Current examples are
> memory added via dax/kmem -- ("System RAM (kmem)") and virtio-mem ("System
> RAM (virtio_mem)"). Note that in some kernel versions "System RAM
> (kmem)" was exposed as "System RAM", but similarly, on lower levels of
> the resource tree.
>
> Let's add anything that contains "System RAM" to the elf core header, so
> it will be dumped for kexec_load(). Handling kexec_file_load() in the
> kernel is similarly getting fixed [1].
Although I don't do a lot of hacking in the crashdump code, this seems
sane to me. As the perpetrator of the "System RAM (kmem)" trick:
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v1 2/3] crashdump/x86: iterate only over actual crash memory ranges
2021-03-23 10:01 [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM David Hildenbrand
2021-03-23 10:01 ` [PATCH v1 1/3] crashdump/x86: dump any kind of "System RAM" David Hildenbrand
@ 2021-03-23 10:01 ` David Hildenbrand
2021-03-23 10:01 ` [PATCH v1 3/3] crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k David Hildenbrand
2021-03-30 8:58 ` [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM David Hildenbrand
3 siblings, 0 replies; 8+ messages in thread
From: David Hildenbrand @ 2021-03-23 10:01 UTC (permalink / raw)
To: kexec; +Cc: David Hildenbrand, Simon Horman
No need to iterate over empty entries.
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
kexec/arch/i386/crashdump-x86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index a301ac8..43e830a 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -988,7 +988,7 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
cmdline_add_elfcorehdr(mod_cmdline, elfcorehdr);
/* Inform second kernel about the presence of ACPI tables. */
- for (i = 0; i < CRASH_MAX_MEMORY_RANGES; i++) {
+ for (i = 0; i < nr_ranges; i++) {
unsigned long start, end, size, type;
if ( !( mem_range[i].type == RANGE_ACPI
|| mem_range[i].type == RANGE_ACPI_NVS
--
2.29.2
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 8+ messages in thread* [PATCH v1 3/3] crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k
2021-03-23 10:01 [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM David Hildenbrand
2021-03-23 10:01 ` [PATCH v1 1/3] crashdump/x86: dump any kind of "System RAM" David Hildenbrand
2021-03-23 10:01 ` [PATCH v1 2/3] crashdump/x86: iterate only over actual crash memory ranges David Hildenbrand
@ 2021-03-23 10:01 ` David Hildenbrand
2021-03-30 8:58 ` [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM David Hildenbrand
3 siblings, 0 replies; 8+ messages in thread
From: David Hildenbrand @ 2021-03-23 10:01 UTC (permalink / raw)
To: kexec; +Cc: David Hildenbrand, Simon Horman
virtio-mem in Linux adds/removes individual memory blocks (e.g., 128 MB
each). Linux merges adjacent memory blocks added by virtio-mem devices, but
we can still end up with a very sparse memory layout when unplugging
memory in corner cases.
Let's increase the maximum number of crash memory ranges from ~2k to 32k.
32k should be sufficient for a very long time.
e_phnum field in the header is 16 bits wide, so we can fit a maximum of
~64k entries in there, shared with other entries (i.e., CPU). Therefore,
using up to 32k memory ranges is fine. (if we ever need more than ~64k,
we can switch to the sh_info field)
Move the temporary xen ranges off the stack, dynamically allocating
memory for them.
Note: We don't have to increase MAX_MEMORY_RANGES, because virtio-mem
added memory is driver managed and always detected and added by a
driver in the kexec'ed kernel; for ordinary kexec, we must not expose
these ranges in the firmware-provided memmap.
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
kexec/arch/i386/crashdump-x86.c | 6 ++++--
kexec/arch/i386/crashdump-x86.h | 3 ++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 43e830a..df84185 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -355,8 +355,8 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
static int get_crash_memory_ranges_xen(struct memory_range **range,
int *ranges, unsigned long lowmem_limit)
{
+ struct e820entry *e820entries;
int j, rc, ret = -1;
- struct e820entry e820entries[CRASH_MAX_MEMORY_RANGES];
unsigned int i;
xc_interface *xc;
@@ -367,6 +367,8 @@ static int get_crash_memory_ranges_xen(struct memory_range **range,
return -1;
}
+ e820entries = xmalloc(sizeof(*e820entries) * CRASH_MAX_MEMORY_RANGES);
+
rc = xc_get_machine_memory_map(xc, e820entries, CRASH_MAX_MEMORY_RANGES);
if (rc < 0) {
@@ -395,7 +397,7 @@ static int get_crash_memory_ranges_xen(struct memory_range **range,
err:
xc_interface_close(xc);
-
+ free(e820entries);
return ret;
}
#else
diff --git a/kexec/arch/i386/crashdump-x86.h b/kexec/arch/i386/crashdump-x86.h
index e4fdc82..479a549 100644
--- a/kexec/arch/i386/crashdump-x86.h
+++ b/kexec/arch/i386/crashdump-x86.h
@@ -22,7 +22,8 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline,
#define X86_64_KERNEL_TEXT_SIZE (512UL*1024*1024)
#define CRASH_MAX_MEMMAP_NR 1024
-#define CRASH_MAX_MEMORY_RANGES (MAX_MEMORY_RANGES + 2)
+
+#define CRASH_MAX_MEMORY_RANGES 32768
/* Backup Region, First 640K of System RAM. */
#define BACKUP_SRC_START 0x00000000
--
2.29.2
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM
2021-03-23 10:01 [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM David Hildenbrand
` (2 preceding siblings ...)
2021-03-23 10:01 ` [PATCH v1 3/3] crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k David Hildenbrand
@ 2021-03-30 8:58 ` David Hildenbrand
2021-04-02 10:06 ` Simon Horman
3 siblings, 1 reply; 8+ messages in thread
From: David Hildenbrand @ 2021-03-30 8:58 UTC (permalink / raw)
To: kexec; +Cc: Baoquan He, Dan Williams, Dave Hansen, Simon Horman
On 23.03.21 11:01, David Hildenbrand wrote:
> Let's properly support dumping any kind of "System RAM" that is not on the
> top level of the kernel resource tree in /proc/iomem, processing any
> /proc/iomem entry that contains "System RAM". In addition, increase
> the maximum number of crash memory ranges to fully support virtio-mem
> even in corner cases where we end up with a lot of individual memory
> ranges.
>
> David Hildenbrand (3):
> crashdump/x86: dump any kind of "System RAM"
> crashdump/x86: iterate only over actual crash memory ranges
> crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k
>
> kexec/arch/i386/crashdump-x86.c | 18 +++++++++++++-----
> kexec/arch/i386/crashdump-x86.h | 3 ++-
> 2 files changed, 15 insertions(+), 6 deletions(-)
>
Gentle ping.
--
Thanks,
David / dhildenb
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM
2021-03-30 8:58 ` [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM David Hildenbrand
@ 2021-04-02 10:06 ` Simon Horman
2021-04-02 11:06 ` David Hildenbrand
0 siblings, 1 reply; 8+ messages in thread
From: Simon Horman @ 2021-04-02 10:06 UTC (permalink / raw)
To: David Hildenbrand; +Cc: kexec, Baoquan He, Dan Williams, Dave Hansen
On Tue, Mar 30, 2021 at 10:58:28AM +0200, David Hildenbrand wrote:
> On 23.03.21 11:01, David Hildenbrand wrote:
> > Let's properly support dumping any kind of "System RAM" that is not on the
> > top level of the kernel resource tree in /proc/iomem, processing any
> > /proc/iomem entry that contains "System RAM". In addition, increase
> > the maximum number of crash memory ranges to fully support virtio-mem
> > even in corner cases where we end up with a lot of individual memory
> > ranges.
> >
> > David Hildenbrand (3):
> > crashdump/x86: dump any kind of "System RAM"
> > crashdump/x86: iterate only over actual crash memory ranges
> > crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k
> >
> > kexec/arch/i386/crashdump-x86.c | 18 +++++++++++++-----
> > kexec/arch/i386/crashdump-x86.h | 3 ++-
> > 2 files changed, 15 insertions(+), 6 deletions(-)
> >
>
> Gentle ping.
Thanks, and sorry for the delay.
Series applied.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v1 0/3] crashdump/x86: dump dax/kmem and virito-mem added System RAM
2021-04-02 10:06 ` Simon Horman
@ 2021-04-02 11:06 ` David Hildenbrand
0 siblings, 0 replies; 8+ messages in thread
From: David Hildenbrand @ 2021-04-02 11:06 UTC (permalink / raw)
To: Simon Horman
Cc: David Hildenbrand, kexec, Baoquan He, Dan Williams, Dave Hansen
> Am 02.04.2021 um 12:16 schrieb Simon Horman <horms@verge.net.au>:
>
> On Tue, Mar 30, 2021 at 10:58:28AM +0200, David Hildenbrand wrote:
>>> On 23.03.21 11:01, David Hildenbrand wrote:
>>> Let's properly support dumping any kind of "System RAM" that is not on the
>>> top level of the kernel resource tree in /proc/iomem, processing any
>>> /proc/iomem entry that contains "System RAM". In addition, increase
>>> the maximum number of crash memory ranges to fully support virtio-mem
>>> even in corner cases where we end up with a lot of individual memory
>>> ranges.
>>>
>>> David Hildenbrand (3):
>>> crashdump/x86: dump any kind of "System RAM"
>>> crashdump/x86: iterate only over actual crash memory ranges
>>> crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k
>>>
>>> kexec/arch/i386/crashdump-x86.c | 18 +++++++++++++-----
>>> kexec/arch/i386/crashdump-x86.h | 3 ++-
>>> 2 files changed, 15 insertions(+), 6 deletions(-)
>>>
>>
>> Gentle ping.
>
> Thanks, and sorry for the delay.
>
> Series applied.
>
No worries - thanks a lot!
Have a nice weekend :)
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 8+ messages in thread