On Fri, Sep 29, 2023 at 01:13:24PM +0300, Shutemov, Kirill wrote: > On Wed, Sep 27, 2023 at 07:46:36PM -0700, Stanislav Kinsburskii wrote: > > I'd answer yes, "System MAP" must be persisted across kexec. > > Could you elaborate on why there should be a mechanism to tell the > > kernel anything special about the existent "System map" in this context? > > Say, one can reserve a CMA region (or a crash kernel region, etc), store > > there some data, and then pass it across kexec. Reserved CMA region will > > still be a part of the "System MAP", won't it? > > Em. When crash kernel starts all System RAM of the the first kernel > becomes E820_TYPE_RESERVED and only memory pre-allocated for crash > scenario becomes E820_TYPE_RAM. See crash_setup_memmap_entries(). > > Can't you go the same path? Report all deposited memory as > E820_TYPE_RESERVED. > Sure I can. This approach will have the corresponding command line option as a requirement, and therefore is less flexible. But if passing device tree across kexec on x86 is the major concern, then of course I can change it the way you suggest. > Or do you have too many deposited memory ranges, so we would run out of > e820 entries? > No, I don't think I have. I can imagine how such a pool with a lot of regions can exhaust e820 table, but the implementation currently proposed is based on CMA and thus limited by 19 entires by default, so I guess running out of e820 entries is unlikely in real world scenarios. Thanks, Stanislav > -- > Kiryl Shutsemau / Kirill A. Shutemov _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
