From: James Morse <james.morse@arm.com> To: David Hildenbrand <david@redhat.com> Cc: kexec@lists.infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Eric Biederman <ebiederm@xmission.com>, Andrew Morton <akpm@linux-foundation.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Anshuman Khandual <anshuman.khandual@arm.com>, Bhupesh Sharma <bhsharma@redhat.com>, Vitaly Kuznetsov <vkuznets@redhat.com> Subject: Re: [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names Date: Mon, 30 Mar 2020 18:17:38 +0100 [thread overview] Message-ID: <e3ae2e24-fdc3-bd6c-db4e-1588f9b031ff@arm.com> (raw) In-Reply-To: <1090cc16-fa6b-8dd2-8c41-22136f733f00@redhat.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com> To: David Hildenbrand <david@redhat.com> Cc: Anshuman Khandual <anshuman.khandual@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Bhupesh Sharma <bhsharma@redhat.com>, kexec@lists.infradead.org, linux-mm@kvack.org, Eric Biederman <ebiederm@xmission.com>, Andrew Morton <akpm@linux-foundation.org>, Will Deacon <will@kernel.org>, Vitaly Kuznetsov <vkuznets@redhat.com>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names Date: Mon, 30 Mar 2020 18:17:38 +0100 [thread overview] Message-ID: <e3ae2e24-fdc3-bd6c-db4e-1588f9b031ff@arm.com> (raw) In-Reply-To: <1090cc16-fa6b-8dd2-8c41-22136f733f00@redhat.com> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-30 17:17 UTC|newest] Thread overview: 264+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-26 18:07 [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use James Morse 2020-03-26 18:07 ` James Morse 2020-03-26 18:07 ` [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image James Morse 2020-03-26 18:07 ` James Morse 2020-03-27 0:43 ` Anshuman Khandual 2020-03-27 0:43 ` Anshuman Khandual 2020-03-27 2:54 ` Baoquan He 2020-03-27 2:54 ` Baoquan He 2020-03-27 15:46 ` James Morse 2020-03-27 15:46 ` James Morse 2020-03-27 2:34 ` Baoquan He 2020-03-27 2:34 ` Baoquan He 2020-03-27 9:30 ` David Hildenbrand 2020-03-27 9:30 ` David Hildenbrand 2020-03-27 16:56 ` James Morse 2020-03-27 16:56 ` James Morse 2020-03-27 17:06 ` David Hildenbrand 2020-03-27 17:06 ` David Hildenbrand 2020-03-27 18:07 ` James Morse 2020-03-27 18:07 ` James Morse 2020-03-27 18:52 ` David Hildenbrand 2020-03-27 18:52 ` David Hildenbrand 2020-03-30 13:00 ` James Morse 2020-03-30 13:00 ` James Morse 2020-03-30 13:13 ` David Hildenbrand 2020-03-30 13:13 ` David Hildenbrand 2020-03-30 17:17 ` James Morse 2020-03-30 17:17 ` James Morse 2020-03-30 18:14 ` David Hildenbrand 2020-03-30 18:14 ` David Hildenbrand 2020-04-10 19:10 ` Andrew Morton 2020-04-10 19:10 ` Andrew Morton 2020-04-10 19:10 ` Andrew Morton 2020-04-11 3:44 ` Baoquan He 2020-04-11 3:44 ` Baoquan He 2020-04-11 3:44 ` Baoquan He 2020-04-11 9:30 ` Russell King - ARM Linux admin 2020-04-11 9:30 ` Russell King - ARM Linux admin 2020-04-11 9:30 ` Russell King - ARM Linux admin 2020-04-11 9:58 ` David Hildenbrand 2020-04-11 9:58 ` David Hildenbrand 2020-04-11 9:58 ` David Hildenbrand 2020-04-12 5:35 ` Baoquan He 2020-04-12 5:35 ` Baoquan He 2020-04-12 5:35 ` Baoquan He 2020-04-12 8:08 ` Russell King - ARM Linux admin 2020-04-12 8:08 ` Russell King - ARM Linux admin 2020-04-12 8:08 ` Russell King - ARM Linux admin 2020-04-12 19:52 ` Eric W. Biederman 2020-04-12 19:52 ` Eric W. Biederman 2020-04-12 19:52 ` Eric W. Biederman 2020-04-12 20:37 ` Bhupesh SHARMA 2020-04-12 20:37 ` Bhupesh SHARMA 2020-04-12 20:37 ` Bhupesh SHARMA 2020-04-13 2:37 ` Baoquan He 2020-04-13 2:37 ` Baoquan He 2020-04-13 2:37 ` Baoquan He 2020-04-13 13:15 ` Eric W. Biederman 2020-04-13 13:15 ` Eric W. Biederman 2020-04-13 13:15 ` Eric W. Biederman 2020-04-13 23:01 ` Andrew Morton 2020-04-13 23:01 ` Andrew Morton 2020-04-13 23:01 ` Andrew Morton 2020-04-14 6:13 ` Eric W. Biederman 2020-04-14 6:13 ` Eric W. Biederman 2020-04-14 6:13 ` Eric W. Biederman 2020-04-14 6:40 ` Baoquan He 2020-04-14 6:40 ` Baoquan He 2020-04-14 6:40 ` Baoquan He 2020-04-14 6:51 ` Baoquan He 2020-04-14 6:51 ` Baoquan He 2020-04-14 6:51 ` Baoquan He 2020-04-14 8:00 ` David Hildenbrand 2020-04-14 8:00 ` David Hildenbrand 2020-04-14 8:00 ` David Hildenbrand 2020-04-14 9:22 ` Baoquan He 2020-04-14 9:22 ` Baoquan He 2020-04-14 9:22 ` Baoquan He 2020-04-14 9:22 ` Baoquan He 2020-04-14 9:37 ` David Hildenbrand 2020-04-14 9:37 ` David Hildenbrand 2020-04-14 9:37 ` David Hildenbrand 2020-04-14 9:37 ` David Hildenbrand 2020-04-14 14:39 ` Baoquan He 2020-04-14 14:39 ` Baoquan He 2020-04-14 14:39 ` Baoquan He 2020-04-14 14:39 ` Baoquan He 2020-04-14 14:49 ` David Hildenbrand 2020-04-14 14:49 ` David Hildenbrand 2020-04-14 14:49 ` David Hildenbrand 2020-04-14 14:49 ` David Hildenbrand 2020-04-15 2:35 ` Baoquan He 2020-04-15 2:35 ` Baoquan He 2020-04-15 2:35 ` Baoquan He 2020-04-15 2:35 ` Baoquan He 2020-04-16 13:31 ` David Hildenbrand 2020-04-16 13:31 ` David Hildenbrand 2020-04-16 13:31 ` David Hildenbrand 2020-04-16 13:31 ` David Hildenbrand 2020-04-16 14:02 ` Baoquan He 2020-04-16 14:02 ` Baoquan He 2020-04-16 14:02 ` Baoquan He 2020-04-16 14:02 ` Baoquan He 2020-04-16 14:09 ` David Hildenbrand 2020-04-16 14:09 ` David Hildenbrand 2020-04-16 14:09 ` David Hildenbrand 2020-04-16 14:09 ` David Hildenbrand 2020-04-16 14:36 ` Baoquan He 2020-04-16 14:36 ` Baoquan He 2020-04-16 14:36 ` Baoquan He 2020-04-16 14:36 ` Baoquan He 2020-04-16 14:47 ` David Hildenbrand 2020-04-16 14:47 ` David Hildenbrand 2020-04-16 14:47 ` David Hildenbrand 2020-04-16 14:47 ` David Hildenbrand 2020-04-21 13:29 ` David Hildenbrand 2020-04-21 13:29 ` David Hildenbrand 2020-04-21 13:29 ` David Hildenbrand 2020-04-21 13:29 ` David Hildenbrand 2020-04-21 13:57 ` David Hildenbrand 2020-04-21 13:57 ` David Hildenbrand 2020-04-21 13:57 ` David Hildenbrand 2020-04-21 13:57 ` David Hildenbrand 2020-04-21 13:59 ` Eric W. Biederman 2020-04-21 13:59 ` Eric W. Biederman 2020-04-21 13:59 ` Eric W. Biederman 2020-04-21 13:59 ` Eric W. Biederman 2020-04-21 14:30 ` David Hildenbrand 2020-04-21 14:30 ` David Hildenbrand 2020-04-21 14:30 ` David Hildenbrand 2020-04-21 14:30 ` David Hildenbrand 2020-04-22 9:17 ` Baoquan He 2020-04-22 9:17 ` Baoquan He 2020-04-22 9:17 ` Baoquan He 2020-04-22 9:17 ` Baoquan He 2020-04-22 9:24 ` David Hildenbrand 2020-04-22 9:24 ` David Hildenbrand 2020-04-22 9:24 ` David Hildenbrand 2020-04-22 9:24 ` David Hildenbrand 2020-04-22 9:57 ` Baoquan He 2020-04-22 9:57 ` Baoquan He 2020-04-22 9:57 ` Baoquan He 2020-04-22 9:57 ` Baoquan He 2020-04-22 10:05 ` David Hildenbrand 2020-04-22 10:05 ` David Hildenbrand 2020-04-22 10:05 ` David Hildenbrand 2020-04-22 10:05 ` David Hildenbrand 2020-04-22 10:36 ` Baoquan He 2020-04-22 10:36 ` Baoquan He 2020-04-22 10:36 ` Baoquan He 2020-04-22 10:36 ` Baoquan He 2020-04-14 9:16 ` Dave Young 2020-04-14 9:16 ` Dave Young 2020-04-14 9:16 ` Dave Young 2020-04-14 9:38 ` Dave Young 2020-04-14 9:38 ` Dave Young 2020-04-14 9:38 ` Dave Young 2020-04-14 7:05 ` David Hildenbrand 2020-04-14 7:05 ` David Hildenbrand 2020-04-14 7:05 ` David Hildenbrand 2020-04-14 16:55 ` James Morse 2020-04-14 16:55 ` James Morse 2020-04-14 16:55 ` James Morse 2020-04-14 17:41 ` David Hildenbrand 2020-04-14 17:41 ` David Hildenbrand 2020-04-14 17:41 ` David Hildenbrand 2020-04-15 20:33 ` Eric W. Biederman 2020-04-15 20:33 ` Eric W. Biederman 2020-04-15 20:33 ` Eric W. Biederman 2020-04-22 12:28 ` James Morse 2020-04-22 12:28 ` James Morse 2020-04-22 12:28 ` James Morse 2020-04-22 15:25 ` Eric W. Biederman 2020-04-22 15:25 ` Eric W. Biederman 2020-04-22 15:25 ` Eric W. Biederman 2020-04-22 16:40 ` David Hildenbrand 2020-04-22 16:40 ` David Hildenbrand 2020-04-22 16:40 ` David Hildenbrand 2020-04-23 16:29 ` Eric W. Biederman 2020-04-23 16:29 ` Eric W. Biederman 2020-04-23 16:29 ` Eric W. Biederman 2020-04-24 7:39 ` David Hildenbrand 2020-04-24 7:39 ` David Hildenbrand 2020-04-24 7:39 ` David Hildenbrand 2020-04-24 7:41 ` David Hildenbrand 2020-04-24 7:41 ` David Hildenbrand 2020-04-24 7:41 ` David Hildenbrand 2020-05-01 16:55 ` James Morse 2020-05-01 16:55 ` James Morse 2020-05-01 16:55 ` James Morse 2020-03-26 18:07 ` [PATCH 2/3] mm/memory_hotplug: Allow arch override of non boot memory resource names James Morse 2020-03-26 18:07 ` James Morse 2020-03-27 9:59 ` David Hildenbrand 2020-03-27 9:59 ` David Hildenbrand 2020-03-27 15:39 ` James Morse 2020-03-27 15:39 ` James Morse 2020-03-30 13:23 ` David Hildenbrand 2020-03-30 13:23 ` David Hildenbrand 2020-03-30 17:17 ` James Morse [this message] 2020-03-30 17:17 ` James Morse 2020-04-02 5:49 ` Dave Young 2020-04-02 5:49 ` Dave Young 2020-04-02 5:49 ` Dave Young 2020-04-02 6:12 ` piliu 2020-04-02 6:12 ` piliu 2020-04-02 6:12 ` piliu 2020-04-14 17:21 ` James Morse 2020-04-14 17:21 ` James Morse 2020-04-14 17:21 ` James Morse 2020-04-15 20:36 ` Eric W. Biederman 2020-04-15 20:36 ` Eric W. Biederman 2020-04-15 20:36 ` Eric W. Biederman 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-05-09 0:45 ` Andrew Morton 2020-05-09 0:45 ` Andrew Morton 2020-05-09 0:45 ` Andrew Morton 2020-05-11 8:35 ` David Hildenbrand 2020-05-11 8:35 ` David Hildenbrand 2020-05-11 8:35 ` David Hildenbrand 2020-03-26 18:07 ` [PATCH 3/3] arm64: memory: Give hotplug memory a different resource name James Morse 2020-03-26 18:07 ` James Morse 2020-03-30 19:01 ` David Hildenbrand 2020-03-30 19:01 ` David Hildenbrand 2020-04-15 20:37 ` Eric W. Biederman 2020-04-15 20:37 ` Eric W. Biederman 2020-04-15 20:37 ` Eric W. Biederman 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-03-27 2:11 ` [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use Baoquan He 2020-03-27 2:11 ` Baoquan He 2020-03-27 15:40 ` James Morse 2020-03-27 15:40 ` James Morse 2020-03-27 9:27 ` David Hildenbrand 2020-03-27 9:27 ` David Hildenbrand 2020-03-27 15:42 ` James Morse 2020-03-27 15:42 ` James Morse 2020-03-30 13:18 ` David Hildenbrand 2020-03-30 13:18 ` David Hildenbrand 2020-03-30 13:55 ` Baoquan He 2020-03-30 13:55 ` Baoquan He 2020-03-30 17:17 ` James Morse 2020-03-30 17:17 ` James Morse 2020-03-31 3:46 ` Dave Young 2020-03-31 3:46 ` Dave Young 2020-04-14 17:31 ` James Morse 2020-04-14 17:31 ` James Morse 2020-04-14 17:31 ` James Morse 2020-03-31 3:38 ` Dave Young 2020-03-31 3:38 ` Dave Young 2020-04-15 20:29 ` Eric W. Biederman 2020-04-15 20:29 ` Eric W. Biederman 2020-04-15 20:29 ` Eric W. Biederman 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-04-22 12:14 ` James Morse 2020-04-22 13:04 ` Eric W. Biederman 2020-04-22 13:04 ` Eric W. Biederman 2020-04-22 13:04 ` Eric W. Biederman 2020-04-22 15:40 ` James Morse 2020-04-22 15:40 ` James Morse 2020-04-22 15:40 ` James Morse
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=e3ae2e24-fdc3-bd6c-db4e-1588f9b031ff@arm.com \ --to=james.morse@arm.com \ --cc=akpm@linux-foundation.org \ --cc=anshuman.khandual@arm.com \ --cc=bhsharma@redhat.com \ --cc=catalin.marinas@arm.com \ --cc=david@redhat.com \ --cc=ebiederm@xmission.com \ --cc=kexec@lists.infradead.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mm@kvack.org \ --cc=vkuznets@redhat.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.