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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1F0AC83F10 for ; Thu, 31 Aug 2023 17:26:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 111CE280004; Thu, 31 Aug 2023 13:26:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C351280002; Thu, 31 Aug 2023 13:26:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ECC14280004; Thu, 31 Aug 2023 13:26:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D86BB280002 for ; Thu, 31 Aug 2023 13:26:33 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A6F62A039B for ; Thu, 31 Aug 2023 17:26:33 +0000 (UTC) X-FDA: 81185079066.01.353B854 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by imf03.hostedemail.com (Postfix) with ESMTP id C323F2001A for ; Thu, 31 Aug 2023 17:26:31 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=k9RJ2Akx; spf=pass (imf03.hostedemail.com: domain of skinsburskii@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=skinsburskii@linux.microsoft.com; dmarc=pass (policy=none) header.from=linux.microsoft.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693502792; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nfTPUyS74OZsYR901USpAVlQVSz9pTNKt+fbqvjENVU=; b=mub5GrXGzdZII7PxGh8OTlW4iG1FAOPxIfiWXj/opjDcSWeNajFdLiI5nY8j3a3OjbW/4y kAvy4mMiD4nba+DjwmxJTDBYALMxsEgy8wn1K536k4PQ83ChVXyFmnEmx9zPf5TnPEDK1B SRUJsDBlK0d+AgoU36jhuPBU4jmOgkI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693502792; a=rsa-sha256; cv=none; b=N1JWdQcXH/26s3zWdOsWm2kRkJq/Ob/df7OLxtoGYX7hxsqPzvzjccpZ4K5oB56lsqsN+F HjmfJZ3n91JF5CW9uQMjIonNwDAQql6jHOeQM/+hkpJ2ixiXCs2mg3UOngKwsgSIG0oVGs kyDMaKzQQsMO/pcNS42Pyznx9FxRrfc= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.microsoft.com header.s=default header.b=k9RJ2Akx; spf=pass (imf03.hostedemail.com: domain of skinsburskii@linux.microsoft.com designates 13.77.154.182 as permitted sender) smtp.mailfrom=skinsburskii@linux.microsoft.com; dmarc=pass (policy=none) header.from=linux.microsoft.com Received: from skinsburskii. (unknown [167.220.2.160]) by linux.microsoft.com (Postfix) with ESMTPSA id 576FD212A787; Thu, 31 Aug 2023 10:26:30 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 576FD212A787 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1693502790; bh=nfTPUyS74OZsYR901USpAVlQVSz9pTNKt+fbqvjENVU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=k9RJ2AkxTRu5KW6j3vuPuIkv8RGXzQueX0k4tMowfXafF6KiTLt+HqRDsZfJO8iNR w3tVH/MsHxBW3JMnBMO6EPVN/0rAft0KVqSEGIYrvdhhEF/HCQxhtA88KbIydILFRS 5KSgCHtsY16bUrUWv5M5dGAa07Rp0Fzr09Wyyqr8= Date: Wed, 30 Aug 2023 19:24:43 -0700 From: Stanislav Kinsburskii To: Arnd Bergmann Cc: Alexander Graf , "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 Message-ID: <20230831022443.GA10414@skinsburskii.> 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> <1697efce-665a-43d5-b0be-7c03c0a4d850@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1697efce-665a-43d5-b0be-7c03c0a4d850@app.fastmail.com> X-Rspamd-Queue-Id: C323F2001A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: gxfaaxbtekqarkfgkp8ogyh8fyt8etdc X-HE-Tag: 1693502791-880898 X-HE-Meta: U2FsdGVkX19noeh7P7rvZuRPexcEAGqiyA7doyHO8sOKD18eZwxdv3h+Evrs4nb/0FpbqoaAFSRbGhwyCZZmJLeWP1EvpTrHm/7eniv0Rs1YSW1Psn7r8L7IRoc6croRpgA/btCC2zByo5bCVSEhuiKZspThZlmD5jdT6LFheFzxkiJ8fb+7Sl+OHBrnxzV3FomzfSNlG6zwo1mMqdMa6kPUB9x7QFc1zanlVOrA9lgXjnWzm5hvKXE8gjcKNsuLjmAL4CJStVMfY7pvC1vz6PG6aYfYnsFe+Nj3tlgpwCjI51S45f0+UAEmfJMa8xruPeHy1oZhCoiIjf5wC20QXCwOIZ8gbXV9BvpQtJ6hDjZTraYsGbl3480SVJt+B3fAbo2uyPZdTI8L7DVmSp3WThFr9j0piQ56qCuLK+32SNfmbb7xTfC+Z9Hgjz14oqV8DIBtSCXqaMjRbQstRJhLzTA7aBR7EY4/CC2Gu30pLRSlRLlshhP5gWWm1v4CwPUaGHgsPmEODzHFn8Vmt2buTUAPNJmwHcM+aBk7tvovAXwFoTtq4IH+OK+LDs2Yp68faiy0qsIJGysDZ2XUZFls7yl2cBxNQ3MAhLPNrPM2EgOj/TQqos/+aWIb8cRXaSDIdGuowFXMgeCdXHc/65ZvJyJV2i164Q+kl4mbdjaotoqEW/qoi3Mxz50+q+iNf9GF0Uvdys+8t7si+UIvpUcx2twIZ8lJoy7IVUryw9SlfO9TKrhTZFwVR594/rGj66YwtSTRxsXsYQKhaSPLW3o8nBFUXQZ+ftVLhMGfVmwglP4Kjvf3r8HR+ml1ZwheorqYxZG73ebbyKTDnLYpWTK7zP73qwswBenBmODmc14S4QoSuMlfqReZySUVsX0j/AmT/FUHvStaBQa7HpAvzYWf+AWKi+bCQWdZyZkHQn9YxKPJqesEnb3T1Zm3MGyN1mDaI6iFqZpd9TV/UkUm5BH L2SKCdZA TArm3rQbIz9WwIHZxUamobmIabhF8r7iyEi6FjRTy27RJpva4aSdFa9Wr1SsEzv4geDg47gJwm+PgjNlRpdcD9vQoIE6LvFiD/a3ePVae/pnNdZGCZ7cLLi1oTkxtaS30qNTbVZAMmHOXfWa5IHEje209Ado9q6VfF4vW34+BPFKVot7iWwwq5QnC8FlAeQCvhgv8UM0znl2wtQqOySve+wWG6gL5bTxLiG0w5E30MWD0p/YlvB3fPDV4YB74gJrNyJqwW4eixbC1dCPKVy5ciiXPovw0ZqkOXcg+sfFFIE+/y5c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Aug 30, 2023 at 07:39:18PM -0400, Arnd Bergmann wrote: > 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. > I see. Using DT instead of introducing another format to pass metadata is quite tempting. The only problem I see here is that it enforces a user of x86 host to use device tree. I guess such a device tree can be fully constructred in kernel and then added to kexec parameters by kernel itself thus keeping the such matadata management independent from user setup. But then how to combine this in-kernel device tree with the one, provided by user? Also, AFAIK user can override device tree via kexec paramaters, so I guess placing kernel-specific data into a DT, controlled by user, isn't very reliable. Is there a way to pass multiple device trees over kexec? Or should there be an implicit extention to patch user provided DT with kernel metadata before kexec? Thanks, Stanislav > Arnd