From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1781C83F15 for ; Wed, 30 Aug 2023 23:39:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344521AbjH3Xju (ORCPT ); Wed, 30 Aug 2023 19:39:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240999AbjH3Xjt (ORCPT ); Wed, 30 Aug 2023 19:39:49 -0400 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB442C9; Wed, 30 Aug 2023 16:39:45 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 9DB6C32008FB; Wed, 30 Aug 2023 19:39:40 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Wed, 30 Aug 2023 19:39:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1693438780; x=1693525180; bh=M9 gCOekIM2huAR+ziQ0XQjqHbftSph1uDZZYkRIXuOY=; b=h0nbIFQABAhkUtYLOb Nc80hXI+gmNKqPcCnLnMjBtZq38DP3F7i1vexStaKEZtfIl0l0X4JJ7jLPZf4CWp RrYIbrwHVosg+gMbqdOFjoi/HpXZSgXAbYRfWfQnp9sXkxcGwRFe+hSjkOi5agDO 4pcMR6WRbtzbtH0r9BJ8lLBtrfUBWPls5LdOEYPwuBJ7FPJkswg5Y0A+k40RbRjl GgK0xD3yx8j+iVu13aZImwLK0pZO+CVOk3I1zQSb99e5L+7fKTieHfCfSkxMBmby mUvB8wnqOTYDolIXih7WcxLG6jqiSwBXsnCUt4WeJDZ3/hRvil1yMyQYTNiVVppM SEmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1693438780; x=1693525180; bh=M9gCOekIM2huA R+ziQ0XQjqHbftSph1uDZZYkRIXuOY=; b=QEKf/B1hGP+3+lNgIbPPHKf6dWjAv Kl3cKbpGmMeyoz1x39J42uhNWzDtFm86wco3daCRHL5X1YJkdPCQg+sJWQQFsHOG XEzju8k85UTDZaiG+HB69EI5g6cLpVBSCQ0tq5lnJfiFnOrVch9v5NPiHAtgpyJ8 0/uergth478HofL+FedcUigFE9Ykbqk8F3BEYaxI3eH/wuHlaRmqT29W/80I70vn Y+7Bd9DyacXJSbZ7+NTNuTiZ5nIbDGQMTOF/h0XdX5pOs5I2HsQgPDEmCYNxfL3M 3L5ADpyteoc67NJRZnq/c+h2gms0EueCAIfdjTSTPOq8EAyg0KpZChpaQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefledgvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 27699B60089; Wed, 30 Aug 2023 19:39:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-701-g9b2f44d3ee-fm-20230823.001-g9b2f44d3 Mime-Version: 1.0 Message-Id: <1697efce-665a-43d5-b0be-7c03c0a4d850@app.fastmail.com> In-Reply-To: <82416797-01aa-471a-a737-471297e37c4c@amazon.de> References: <64e7cbf7.050a0220.114c7.b70dSMTPIN_ADDED_BROKEN@mx.google.com> <2023082506-enchanted-tripping-d1d5@gregkh> <20230823024500.GA25462@skinsburskii.> <20230829220740.GA26605@skinsburskii.> <82416797-01aa-471a-a737-471297e37c4c@amazon.de> Date: Wed, 30 Aug 2023 19:39:18 -0400 From: "Arnd Bergmann" To: "Alexander Graf" , "Stanislav Kinsburskii" Cc: "Gowans, James" , "Greg Kroah-Hartman" , "Mike Rapoport" , "madvenka@linux.microsoft.com" , "anthony.yznaga@oracle.com" , "steven.sistare@oracle.com" , "Stanislav Kinsburskii" , "linux-kernel@vger.kernel.org" , "Sean Christopherson" , "Paolo Bonzini" , "K. Y. Srinivasan" , "Wei Liu" , "anrayabh@linux.microsoft.com" , "dragan.cvetic@amd.com" , "jinankjain@linux.microsoft.com" , "derek.kiernan@amd.com" , "linux-mm@kvack.org" , "Andrew Morton" , kexec@lists.infradead.org, iommu@lists.linux.dev, kvm Subject: Re: [RFC PATCH] Introduce persistent memory pool Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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