>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >>> index 0a54ffac8c68..69b03dd7fc74 100644 >>> --- a/mm/memory_hotplug.c >>> +++ b/mm/memory_hotplug.c >>> @@ -42,6 +42,10 @@ >>> #include "internal.h" >>> #include "shuffle.h" >>> >>> +#ifndef MEMORY_HOTPLUG_RES_NAME >>> +#define MEMORY_HOTPLUG_RES_NAME "System RAM" >>> +#endif >> >> So I assume changing this for all architectures would result in some >> user space tool breaking? Are we aware of any? > > Last time we had to touch arm64's /proc/iomem strings I went through debian's > codesearch for stuff that reads it, kexec-tools was the only thing that parsed > it in anger. (From memory, the other tools were looking for PCIe windows to do > firmware flashing..) > > Looking again, having qualifiers on the end of 'System RAM' looks like it could > confuse 's390-tools's detect_mem_chunks parser. Good to know, we should find out if this could work. > > It looks like the strings that come out of 'FIRMWARE_MEMMAP' are a duplicate set. > > >> I do wonder if we should simply change it for all architectures if possible. > > If its possible that would be great. But I suspect that ship has sailed, > changing it on other architectures could break some fragile parsing code. I assume any parser has to be prepared for new types showing up. Otherwise these would not be future proof. The question is if a common prefix is problematic. E.g., Use "Hotplugged System RAM" instead of "System RAM (hotplug)" > > I'm wary of changing it on arm64, the only thing that makes it tolerable is that > memory hot-add was relatively recently merged, and we don't anticipate it being > widely used until you can remove memory as well. > > Changing it on arm64 is to prevent today's versions of kexec-tools from > accidentally placing the new kernel in memory that wasn't described at boot. > This leads to an unhandled exception during boot[0] because the kernel can't > access itself via the mapping of all memory. (hotpluggable regions are only > discovered by suitably configured ACPI systems much later) I want the very same for virtio-mem (initially x86-only, but later open for all archs). Can also be interesting for Hyper-V. kexec should not try to use hotplugged memory as kexec target, as memory blocks can be partially inaccessible. Of course, I can provide an interface to override the name via add_memory(), but having it on all architectures handled in a similar way right from the start would be nicer. -- Thanks, David / dhildenb _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
