[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20230929101324.jgixt4jmqialchno@box.shutemov.name>
Date: Fri, 29 Sep 2023 13:13:24 +0300
From: "Shutemov, Kirill" <kirill.shutemov@...el.com>
To: Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>
Cc: Dave Hansen <dave.hansen@...el.com>, Baoquan He <bhe@...hat.com>,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
ebiederm@...ssion.com, akpm@...ux-foundation.org,
stanislav.kinsburskii@...il.com, corbet@....net,
linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
linux-mm@...ck.org, kys@...rosoft.com, jgowans@...zon.com,
wei.liu@...nel.org, arnd@...db.de, gregkh@...uxfoundation.org,
graf@...zon.de, pbonzini@...hat.com
Subject: Re: [RFC PATCH v2 0/7] Introduce persistent memory pool
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.
Or do you have too many deposited memory ranges, so we would run out of
e820 entries?
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists