linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Alexander Graf" <graf@amazon.de>,
	"Stanislav Kinsburskii" <skinsburskii@linux.microsoft.com>
Cc: "Gowans, James" <jgowans@amazon.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"madvenka@linux.microsoft.com" <madvenka@linux.microsoft.com>,
	"anthony.yznaga@oracle.com" <anthony.yznaga@oracle.com>,
	"steven.sistare@oracle.com" <steven.sistare@oracle.com>,
	"Stanislav Kinsburskii" <stanislav.kinsburskii@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Sean Christopherson" <seanjc@google.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	"Wei Liu" <wei.liu@kernel.org>,
	"anrayabh@linux.microsoft.com" <anrayabh@linux.microsoft.com>,
	"dragan.cvetic@amd.com" <dragan.cvetic@amd.com>,
	"jinankjain@linux.microsoft.com" <jinankjain@linux.microsoft.com>,
	"derek.kiernan@amd.com" <derek.kiernan@amd.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	kexec@lists.infradead.org, iommu@lists.linux.dev,
	kvm <kvm@vger.kernel.org>
Subject: Re: [RFC PATCH] Introduce persistent memory pool
Date: Wed, 30 Aug 2023 19:39:18 -0400	[thread overview]
Message-ID: <1697efce-665a-43d5-b0be-7c03c0a4d850@app.fastmail.com> (raw)
In-Reply-To: <82416797-01aa-471a-a737-471297e37c4c@amazon.de>

On Wed, Aug 30, 2023, at 03:20, Alexander Graf wrote:
> On 30.08.23 00:07, Stanislav Kinsburskii wrote:
>> On Mon, Aug 28, 2023 at 10:50:19PM +0200, Alexander Graf wrote:

>> Device tree or ACPI are options indeed. However AFAIU in case of DT user
>> space has to involved into the picture to modify and complie it, while
>> ACPI isn't flexible or easily extendable.
>> Also, AFAIU both these standards were designed with passing
>> hardware-specific data in mind from bootstrap software to an OS kernel
>> and thus were never really intended to be used for creating a persistent
>> state accross kexec.
>> To me, an attempt to use either of them to pass kernel-specific data looks
>> like an abuse (or misuse) excused by the simplicity of implementation.
>
>
> What I was describing above is that the Linux boot protocol already has 
> natural ways to pass a DT (arm) or set of ACPI tables (x86) to the 
> target kernel. Whatever we do here should either piggy back on top of 
> those natural mechanisms (e.g. /chosen node in DT) or be on the same 
> level (e.g. pass DT in one register, pass metadata structure in another 
> register).
>
> When it comes to the actual content of the metadata, I'm personally also 
> leaning towards DT. We already have libfdt inside the kernel. It gives 
> is a very simple, well understood structured file format that you can 
> extend, version, etc etc. And the kernel has mechanisms to modify fdt 
> contents.

Agreed. This also makes a lot of sense since the fdt format was
originally introduced for this exact purpose, to be a key-value
store to pass data from the running kernel to the next one after
kexec when the original source of the data (originally open
firmware) is gone. It only turned into the generic way to
describe embedded systems later on, but both the fdt binary
format and the kexec infrastructure for manipulating and
passing the blob should be easy to reuse for additional purposes
as long as the contents are put into appropriate namespaces that
don't clash with existing usage.

       Arnd


  reply	other threads:[~2023-08-30 23:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <64e7cbf7.050a0220.114c7.b70dSMTPIN_ADDED_BROKEN@mx.google.com>
     [not found] ` <2023082506-enchanted-tripping-d1d5@gregkh>
2023-08-23  1:36   ` Stanislav Kinsburskii
     [not found]   ` <c26ad989dcc6737dd295e980c78ef53740098810.camel@amazon.com>
2023-08-23  2:45     ` Stanislav Kinsburskii
2023-08-28 20:50       ` Alexander Graf
2023-08-29 22:07         ` Stanislav Kinsburskii
2023-08-30  7:20           ` Alexander Graf
2023-08-30 23:39             ` Arnd Bergmann [this message]
2023-08-31  2:24               ` Stanislav Kinsburskii
     [not found]   ` <64e8f6dd.050a0220.edb3c.c045SMTPIN_ADDED_BROKEN@mx.google.com>
2023-08-26  7:45     ` Greg Kroah-Hartman
2023-08-23  6:15       ` Stanislav Kinsburskii
     [not found]       ` <64ea25cd.650a0220.642cc.50e6SMTPIN_ADDED_BROKEN@mx.google.com>
2023-08-26 17:02         ` Greg Kroah-Hartman
2023-08-23  6:21           ` Stanislav Kinsburskii
     [not found]           ` <64ea3699.170a0220.13ee0.5c3aSMTPIN_ADDED_BROKEN@mx.google.com>
2023-08-26 20:04             ` Greg Kroah-Hartman
2023-08-31 14:18               ` Paolo Bonzini
2023-08-31  2:37                 ` Stanislav Kinsburskii

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=1697efce-665a-43d5-b0be-7c03c0a4d850@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=anrayabh@linux.microsoft.com \
    --cc=anthony.yznaga@oracle.com \
    --cc=derek.kiernan@amd.com \
    --cc=dragan.cvetic@amd.com \
    --cc=graf@amazon.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=iommu@lists.linux.dev \
    --cc=jgowans@amazon.com \
    --cc=jinankjain@linux.microsoft.com \
    --cc=kexec@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=madvenka@linux.microsoft.com \
    --cc=pbonzini@redhat.com \
    --cc=rppt@kernel.org \
    --cc=seanjc@google.com \
    --cc=skinsburskii@linux.microsoft.com \
    --cc=stanislav.kinsburskii@gmail.com \
    --cc=steven.sistare@oracle.com \
    --cc=wei.liu@kernel.org \
    /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