Hi David, On 3/30/20 2:23 PM, David Hildenbrand wrote: >>>> 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)" Aha, I went for a (suffix) because that is what 32bit Arm did for the boot alias. >> 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. Great! I assumed these placement requirements would be arm64 specific. > 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. I agree having it the same on all architectures would be good. It sounds like virtio-mem is a better argument for doing this than arm64's firmware memory description. I'll have a read, and maybe post something to linux-arch to do this at rc1. (I assume we'll have a few weeks to make sure arm64 at least uses the same name if it goes on longer) Thanks, James
