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 8AF6BC3600B for ; Tue, 25 Mar 2025 19:19:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF683280010; Tue, 25 Mar 2025 15:19:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA2A328000B; Tue, 25 Mar 2025 15:19:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A91B9280010; Tue, 25 Mar 2025 15:19:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8D1EA28000B for ; Tue, 25 Mar 2025 15:19:53 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 69E7C8066F for ; Tue, 25 Mar 2025 19:19:53 +0000 (UTC) X-FDA: 83261038266.16.093C327 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf12.hostedemail.com (Postfix) with ESMTP id 93A7A4000F for ; Tue, 25 Mar 2025 19:19:51 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=EPbGLGyB; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742930391; a=rsa-sha256; cv=none; b=bGXxBbyL6wYt7cRMdj9U7qIsmTyx+TiP2My11AN7JkhGlxwmPs4rlfH82CprMXkLn85Kpp N5BrS5/Hngez9BvbH0jOzz2mhQeLktZZRLWynFtwZC3AGHPLpuaTq40HKZZY2NRUs+cgIN Djl2cA0VrmuhT3wJ12yC/InfHx8yd4s= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=EPbGLGyB; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf12.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742930391; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ltrpHuBYK3kBPf0/dcifpaTfATvh6/UqwkZCMbrzTs8=; b=r0KpkQD/m6L/3bncSEDOF+t+BXLgg8k3IiDKkFGKBx7vz2HvyQBQZs5o9oisPYleP9u79O oiCoMYPbmg+Eye0lqWZtebpoO29kSrEyybtq4frkHSJD0828si0eYLyIYZH9+PnNog1QUX aoISBeswLEyy3ga50gFSXGYwe8TtVTc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id DD8F1434DC; Tue, 25 Mar 2025 19:19:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95819C4CEE4; Tue, 25 Mar 2025 19:19:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742930390; bh=wafZEi25K9c1JaTWa6sefMLZsC4dbteHbRRbzmLF/cQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EPbGLGyBiB1SvRfjtdKDPGZo2ETHpmtg4qXxmT/GsGNeAR+CaOgpCSQkLho6C5cyc BeFl650l1ufdKyeIojv+r6tvos6q1QYTea+agnc7gVeN//anBFAS8jHYiYDVjzt75S s4ZzhkBDnUKxoUSQebcAdRQCh05nh9CfvgA1nGA7rbw2k4oclzJMZbHrxqVlBm48wb Z621YrYZ+JHXHsHghbHMhKcOrjvBF8Y03gX03F9+y0ZGfKdZwqTAliB69pFxnQnTxA /WTgRa7IozzmoX/kArbLGdEvNkKtPUwcd3I8f3yvhQKyd+ycRUqXs6b97otN3YzUpL HwRTkHR1eqHGg== Date: Tue, 25 Mar 2025 15:19:44 -0400 From: Mike Rapoport To: Frank van der Linden Cc: Changyuan Lyu , linux-kernel@vger.kernel.org, graf@amazon.com, akpm@linux-foundation.org, luto@kernel.org, anthony.yznaga@oracle.com, arnd@arndb.de, ashish.kalra@amd.com, benh@kernel.crashing.org, bp@alien8.de, catalin.marinas@arm.com, dave.hansen@linux.intel.com, dwmw2@infradead.org, ebiederm@xmission.com, mingo@redhat.com, jgowans@amazon.com, corbet@lwn.net, krzk@kernel.org, mark.rutland@arm.com, pbonzini@redhat.com, pasha.tatashin@soleen.com, hpa@zytor.com, peterz@infradead.org, ptyadav@amazon.de, robh+dt@kernel.org, robh@kernel.org, saravanak@google.com, skinsburskii@linux.microsoft.com, rostedt@goodmis.org, tglx@linutronix.de, thomas.lendacky@amd.com, usama.arif@bytedance.com, will@kernel.org, devicetree@vger.kernel.org, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org Subject: Re: [PATCH v5 07/16] kexec: add Kexec HandOver (KHO) generation helpers Message-ID: References: <20250320015551.2157511-1-changyuanl@google.com> <20250320015551.2157511-8-changyuanl@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 93A7A4000F X-Stat-Signature: gkx8gerdq8ne7gg8ukibcwtm9j9er58b X-HE-Tag: 1742930391-727099 X-HE-Meta: U2FsdGVkX18BrKeS0k4eBHvrzbbOM0nPxq4bOC0+mcmfPasEmHtG6uFtqgDn6v0CRlbztDXZcQYcjeTI98FobGSu35Z69dQPfs2JAVELqyA/mxbfq6SOG/v2wUqtXBfaCEAi2z2EY2RPd7X5vpssQmUyYPlGQp3Y7PWjrkk3TVjml0qmSnWCN0f/L88ZcjRD5dQ+wN7lKke9as8B1DiNcyUntI82Wm/UyZuj5u6EFEedlUT48NqiRVVH3ZcXrp4fJudiVjSbIEQsJWx8aSF4fAUcoLgn78ItFJs8wc3w0ZtssY6oIgW+N6vVPgjdRjlJ7IcrpXVSeVflfHl9DTYwAAt+lRVetXrQBdDyiS4zYPzGihchgqVraKzt3qo+YH0IfXwOFmQB1cETNan0G3/CyV7IKbf3FJ9c/95O9AtPH6Znz0XKCE5JGBQ80kcpgScteaNfl/pRXmisAHddV8vP8EgTSnbL29jpLOhZZEci/lDiGl535kRuhAlcD+O2P42DUp+YPwXPCjShy3mZPKo33sxqDnLq9MJs+bozpvk72n/ZuF4qD3REMounhHTvjHUGoFvaVlXnHr6XcDMNw/7VTktKQu+W3oKR5RvesL3mXFRttJG9dXJb8Y35Tq4vHc+4DfFwwwaIZLGHkG8xdjjO7vH5ktRsM2N5VgRWLlCzIXQfQSGYhsYa+1wAnmHvblKWArCxEuIotU7Ewl9gW89yPSfzp7kn0kjjhENJmhGx6cVX8VATcPkMYnK9OSv6tUm5DGwyVAKFtb0znjbLgPvb3FiH6BqFl6OiTcDP8UxMmNHzJaMNJDIk+fetwJB/E0EwjeJ3ER/5kSkrw2K7ohWUrV9iSbOiAwsCig/FACDqMu5amqHVXYY2VXD2tnHJOUnarMXgWC2RhutofxRBpnfe6s5yFBuMtM31HVbpm8GK4XGal6H7F5rQIvqtKwLM4r3wVZ8OGguqU8baoNoSXPR bipnI96L xHdP8y/uuxo4FI3kixjcg9lXxQyZi97Az3ocPQG95+KzjUycdfCz8JyvD44NagAx/EXTCVktwmnq3Kld60imelvne27UJWkxvzpLoPrQm1qvJ0xhnvdJSICPSoCsFVGeeSYeoVIi/ADLZwON2eDR9qcmIozGJ+9zPjwGQRkcL7FR0BSB1twMv4lNQ4SGrGtT6xT1YAwUVrLqURFh5R/YGeDhFQlcIeg2fWxy9+nmWlpbf5K0Gk4MWKwj1iZfDK5YR1nqbEZ1sQyE6fa5imfnSNiHIPGMh6e6sHLCfWG/eSEh4p5Q9BbJzHHjfb6PBE+xSLIgzpwySHYViTrMRhBPKOXIizL71UG9BOpb35qNSdNbDXpQrMf4KuO3yhm0qrJ6pBbIpSEX5v6nVME2wjK7gyYCOoYBIj/+qX2PFSTZ1M2et23o= 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: List-Subscribe: List-Unsubscribe: On Mon, Mar 24, 2025 at 11:40:43AM -0700, Frank van der Linden wrote: > On Wed, Mar 19, 2025 at 6:56 PM Changyuan Lyu wrote: > > > > From: Alexander Graf > > > > Add the core infrastructure to generate Kexec HandOver metadata. Kexec > > HandOver is a mechanism that allows Linux to preserve state - arbitrary > > properties as well as memory locations - across kexec. > > > > It does so using 2 concepts: > > > > 1) State Tree - Every KHO kexec carries a state tree that describes the > > state of the system. The state tree is represented as hash-tables. > > Device drivers can add/remove their data into/from the state tree at > > system runtime. On kexec, the tree is converted to FDT (flattened > > device tree). > > > > 2) Scratch Regions - CMA regions that we allocate in the first kernel. > > CMA gives us the guarantee that no handover pages land in those > > regions, because handover pages must be at a static physical memory > > location. We use these regions as the place to load future kexec > > images so that they won't collide with any handover data. > > > > Signed-off-by: Alexander Graf > > Co-developed-by: Pratyush Yadav > > Signed-off-by: Pratyush Yadav > > Co-developed-by: Mike Rapoport (Microsoft) > > Signed-off-by: Mike Rapoport (Microsoft) > > Co-developed-by: Changyuan Lyu > > Signed-off-by: Changyuan Lyu > > --- > > MAINTAINERS | 2 +- > > include/linux/kexec_handover.h | 109 +++++ > > kernel/Makefile | 1 + > > kernel/kexec_handover.c | 865 +++++++++++++++++++++++++++++++++ > > mm/mm_init.c | 8 + > > 5 files changed, 984 insertions(+), 1 deletion(-) > > create mode 100644 include/linux/kexec_handover.h > > create mode 100644 kernel/kexec_handover.c > [...] > > diff --git a/mm/mm_init.c b/mm/mm_init.c > > index 04441c258b05..757659b7a26b 100644 > > --- a/mm/mm_init.c > > +++ b/mm/mm_init.c > > @@ -30,6 +30,7 @@ > > #include > > #include > > #include > > +#include > > #include "internal.h" > > #include "slab.h" > > #include "shuffle.h" > > @@ -2661,6 +2662,13 @@ void __init mm_core_init(void) > > report_meminit(); > > kmsan_init_shadow(); > > stack_depot_early_init(); > > + > > + /* > > + * KHO memory setup must happen while memblock is still active, but > > + * as close as possible to buddy initialization > > + */ > > + kho_memory_init(); > > + > > mem_init(); > > kmem_cache_init(); > > /* > > > Thanks for the work on this. > > Obviously it needs to happen while memblock is still active - but why > as close as possible to buddy initialization? One reason is to have all memblock allocations done to autoscale the scratch area. Another reason is to keep memblock structures small as long as possible as memblock_reserve()ing the preserved memory would quite inflate them. And it's overall simpler if memblock only allocates from scratch rather than doing some of early allocations from scratch and some elsewhere and still making sure they avoid the preserved ranges. > Ordering is always a sticky issue when it comes to doing things during > boot, of course. In this case, I can see scenarios where code that > runs a little earlier may want to use some preserved memory. The Can you elaborate about such scenarios? > current requirement in the patch set seems to be "after sparse/page > init", but I'm not sure why it needs to be as close as possibly to > buddy init. Why would you say that sparse/page init would be a requirement here? > - Frank -- Sincerely yours, Mike.