On Fri, Oct 01, 2021 at 10:04:24AM +0200, David Hildenbrand wrote: > On 30.09.21 23:21, Mike Rapoport wrote: > > On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote: > > > On 29.09.21 18:39, Mike Rapoport wrote: > > > > Hi, > > > > > > > > On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote: > > > > > Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED. > > > > > Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory > > > > > like ordinary MEMBLOCK_NONE memory -- for example, when selecting memory > > > > > regions to add to the vmcore for dumping in the crashkernel via > > > > > for_each_mem_range(). > > > > Can you please elaborate on the difference in semantics of MEMBLOCK_HOTPLUG > > > > and MEMBLOCK_DRIVER_MANAGED? > > > > Unless I'm missing something they both mark memory that can be unplugged > > > > anytime and so it should not be used in certain cases. Why is there a need > > > > for a new flag? > > > > > > In the cover letter I have "Alternative B: Reuse MEMBLOCK_HOTPLUG. > > > MEMBLOCK_HOTPLUG serves a different purpose, though.", but looking into the > > > details it won't work as is. > > > > > > MEMBLOCK_HOTPLUG is used to mark memory early during boot that can later get > > > hotunplugged again and should be placed into ZONE_MOVABLE if the > > > "movable_node" kernel parameter is set. > > > > > > The confusing part is that we talk about "hotpluggable" but really mean > > > "hotunpluggable": the reason is that HW flags DIMM slots that can later be > > > hotplugged as "hotpluggable" even though there is already something > > > hotplugged. > > > > MEMBLOCK_HOTPLUG name is indeed somewhat confusing, but still it's core > > meaning "this memory may be removed" which does not differ from what > > IORESOURCE_SYSRAM_DRIVER_MANAGED means. > > > > MEMBLOCK_HOTPLUG regions are indeed placed into ZONE_MOVABLE, but more > > importantly, they are avoided when we allocate memory from memblock. > > > > So, in my view, both flags mean that the memory may be removed and it > > should not be used for certain types of allocations. > > The semantics are different: > > MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the > firmware-provided memory map and added to the system early during boot; we > want this memory to be managed by ZONE_MOVABLE with "movable_node" set on > the kernel command line, because only then we want it to be hotpluggable > again. kexec *has to* indicate this memory to the second kernel and can > place kexec-images on this memory. After memory hotunplug, kexec has to be > re-armed. > > MEMBLOCK_DRIVER_MANAGED: memory is not indicated as System RAM" in the > firmware-provided memory map; this memory is always detected and added to > the system by a driver; memory might not actually be physically > hotunpluggable and the ZONE selection does not depend on "movable_core". > kexec *must not* indicate this memory to the second kernel and *must not* > place kexec-images on this memory. Ok, this clarifies. This explanation should be a part of the changelog. The sentences about the zone selection could be probably skipped, because they are less important for this case. E.g something like: MEMBLOCK_HOTPLUG: memory is indicated as "System RAM" in the firmware-provided memory map and added to the system early during boot; kexec *has to* indicate this memory to the second kernel and can place kexec-images on this memory. After memory hotunplug, kexec has to be re-armed. MEMBLOCK_DRIVER_MANAGED: memory is not indicated as "System RAM" in the firmware-provided memory map; this memory is always detected and added to the system by a driver; memory might not actually be physically hotunpluggable. kexec *must not* indicate this memory to the second kernel and *must not* place kexec-images on this memory. -- Sincerely yours, Mike. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
