From: Dan Williams <dan.j.williams@intel.com>
To: Zhuling <zhuling8@huawei.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-nvdimm <linux-nvdimm@lists.01.org>,
Linux MM <linux-mm@kvack.org>, Will Deacon <will@kernel.org>,
Vishal L Verma <vishal.l.verma@intel.com>,
Dave Jiang <dave.jiang@intel.com>,
luanjianhai@huawei.com, luchunhua@huawei.com,
sangyan@huawei.com
Subject: Re: [PATCH] arm64: add pmem module for kernel update
Date: Mon, 4 Jan 2021 21:42:59 -0800 [thread overview]
Message-ID: <CAPcyv4i9mn7SJ6CSY4uH_74f6pRny5aLQhg6Ubf3cDw8kJoWzg@mail.gmail.com> (raw)
In-Reply-To: <20201231053156.24276-1-zhuling8@huawei.com>
Hi Zhuling,
On Wed, Dec 30, 2020 at 10:18 PM Zhuling <zhuling8@huawei.com> wrote:
>
> Category: feature
> Bugzilla: NA
> CVE: NA
These tags can be dropped.
>
> Use reserved memory to create a pmem device to store the
> processes information that dumped before kernel update.
> When you want to use this feature you need to declare by
> "pmemmem=pmem_size:pmem_phystart" in cmdline.
> (exp: pmemmem=100M:0x202000000000)
>
Interesting. I like the feature, but it's not clear to me that a new
command line based configuration scheme is needed. There is the
existing memmap= parameter that on x86 describes a
IORES_DESC_PERSISTENT_MEMORY_LEGACY range. The driver/nvdimm/e820.c
driver could be reworked to attach to the same thing on ARM64.
Then as far as assigning memory to different kernel usages there is
the existing capability in libnvdimm to attach a "personality" to an
nvdimm namespace. I imagine you could write a special signature to the
namespace that libnvdimm would recognize as a KUP reservation
namespace and work generically across any arch.
prev parent reply other threads:[~2021-01-05 5:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-31 5:31 Zhuling
2021-01-05 5:42 ` Dan Williams [this message]
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=CAPcyv4i9mn7SJ6CSY4uH_74f6pRny5aLQhg6Ubf3cDw8kJoWzg@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=luanjianhai@huawei.com \
--cc=luchunhua@huawei.com \
--cc=sangyan@huawei.com \
--cc=vishal.l.verma@intel.com \
--cc=will@kernel.org \
--cc=zhuling8@huawei.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox