On 09/30/22 at 07:40pm, Borislav Petkov wrote: > On Fri, Sep 30, 2022 at 12:11:26PM -0500, Eric DeVolder wrote: > > There is of course a way to enumerate the memory regions in use on the > > machine, that is not what this code needs. In order to compute the maximum > > buffer size needed (this buffer size is computed once), the count of the > > maximum number of memory regions possible (even if not currently in use) is > > what is needed. > > Isn't that max number documented somewhere in memory hotplug docs? Memory hptlug is not limited by a certin or a max number of memory regions, but limited by how large of the linear mapping range which physical can be mapped into. E.g on x86_64, with 4-level page tables, it has 64TB linear mapping range by default. On principle, we can add 64TB of phisical memory into system altogether from booting and memory hotplug. While with KASLR enabled, it has 10TB of linear mapping range by default, see CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING. Means there's only 10TB phisical memory being allowed to be added into system. For the Kconfig CRASH_MAX_MEMORY_RANGES Eric added, it's meaningful to me to set a fixed value which is enough in reality. For extreme testing with special purpose, it could be broken easily, people need decide by self whether the CONFIG_CRASH_MAX_MEMORY_RANGES is enlarged or not. E.g on x86_64, we make a system with memory smaller than 64G, this will cause the memory block size being probed as 256M. Then we hot added many Tera Bytes of physical memory every second memory block after bootup with a shell shell script. It could be easier to manipulate this with virtiomem. Please see function probe_memory_block_size() on x86_64 about the memory block size probing. However, I don't think on real system, this kind of system could really exist, with a tiny memory booted up, a huge memory hot added sparsely. > > Because then you don't need that Kconfig item either. Imagine you're a > distro kernel distributor and you want crash to work on all machines > your kernel works. > > So you go and set that number to max. And that would be the 99% of the > kernel configs out there. > > Which means, you can just set it to max without a Kconfig item. > > > Oh, that would be an error of haste on my part. This should be: > > depends on CRASH_DUMP && MEMORY_HOTPLUG > > You need a Kconfig item which enables all this gunk as MEMORY_HOTPLUG is > not a omnipresent feature. And that Kconfig item should depend on the > other Kconfig items of the technology you need. > > > Baoquan pointed me to: > > > > https://lore.kernel.org/lkml/cover.1656659357.git.naveen.n.rao@xxxxxxxxxxxxxxxxxx/T/ > > In that thread says: > > "- arch_kexec_apply_relocations_add() is only overridden by x86 and s390. > Retain the function prototype for those and move the weak > implementation into the header as a static inline for other > architectures." > > So yes, that's even better. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette > _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
