diff options
author | David Hildenbrand <david@redhat.com> | 2021-03-23 11:01:10 +0100 |
---|---|---|
committer | Simon Horman <horms@verge.net.au> | 2021-04-02 12:05:57 +0200 |
commit | 1bc7bc7649fa29d95c98f6a6d8dd2f08734a865c (patch) | |
tree | ce454311c04daa62a7188237c2f40b4bc548e112 /kexec/phys_to_virt.c | |
parent | 77ff3d6f49e87d071ac27dc49d2ca5a07c9fba6c (diff) |
crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32k
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>
Signed-off-by: Simon Horman <horms@verge.net.au>
Diffstat (limited to 'kexec/phys_to_virt.c')
0 files changed, 0 insertions, 0 deletions