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 15FBDC02198 for ; Mon, 10 Feb 2025 16:04:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C6F76B007B; Mon, 10 Feb 2025 11:04:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 777316B0082; Mon, 10 Feb 2025 11:04:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 618776B0083; Mon, 10 Feb 2025 11:04:15 -0500 (EST) 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 466716B007B for ; Mon, 10 Feb 2025 11:04:15 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id DB86C16010E for ; Mon, 10 Feb 2025 16:04:14 +0000 (UTC) X-FDA: 83104506828.05.FAABDF8 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf22.hostedemail.com (Postfix) with ESMTP id BB39BC001C for ; Mon, 10 Feb 2025 16:04:12 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=IMZF+ghu; spf=pass (imf22.hostedemail.com: domain of robh+dt@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=robh+dt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739203452; a=rsa-sha256; cv=none; b=ttcZ5/wS2Z5PS+CVJYIIfmelqdrA8+wK/RwrqlY3qRWn2mhRRQHALaPyYZD1NmJFGaGFny gxmuW5fo7hkaytduwO0i8rJVSn+lqs+tktkcaMDWMRxLO4M4DvbgKboUQpAzi2+8BODHxO HqT6ixSGK956DiQVFGU3F3gJHJRiXA4= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=IMZF+ghu; spf=pass (imf22.hostedemail.com: domain of robh+dt@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=robh+dt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739203452; 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=iMSmHPU88YDOwPSpB5j+WYq7IwFLmL60+7nFTkoWpv8=; b=YwRMhTiB3LkXriSRSGJF+rtZXNSiYpt/uorbqUpD560N9C0H1E+f/R0p7m/Wzduy6CYTpV lxpyA29mqkKELJfo1OGoEhSpSybdNtp5Mp1SuvajA8NB41ossS9HUzBrHDtBVWHfbcJIZZ jWk4rDn7KleqDE2liXYzOsI49zDYe6U= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 6AD05A418EE for ; Mon, 10 Feb 2025 16:02:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9026CC4CEF5 for ; Mon, 10 Feb 2025 16:04:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739203451; bh=MmLzTVOIrpo7J0HmbhxBdjKvlFVJINa0c786cp4K2is=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IMZF+ghuSiCCJz57Q5USpgV4CW3vxkE+nfMG1knu6gzbU8ZVVARB0CrktiwrIk67E Hp+1zFYkDBupPWkLP2fek6SjxBtdd8uZX3bsyrNGaGd3VDsFNAQzMV0B8Bw7PLqno7 J8yGHYrFy3lE1q9NnvTqoTJ6L6/fNTihHlNov7BXlXsi3mInlQtMMtxsIsIU8E/YP2 6fuhEdcGiIM2KpifkoHYPYf7AyXzUlFejV237V6OD7muNrezl//ORBJCZM9V0Z2cGP fe78vxqe0+Y6PyqE84mgPUSfNDFYrpSDzRGZFIFOrU6co1irCDDPsKdgFbxPQ6BLzB vldIL+nl53Ugw== Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5de4c7720bcso5034102a12.0 for ; Mon, 10 Feb 2025 08:04:11 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUhRZUGQQHLik+dVo+lKMXxsyvoDwcUgDXXfB0b/kAU8b7v7lr03AP3IzWjfTOHJ78OtoLYKPh0SA==@kvack.org X-Gm-Message-State: AOJu0YxG3abOotnR/3wTVz/kKlP9cY1pAi0XkzESOkxZ3sW/AOrEG7Nh b5epYwpwgmWc0FUOvLeE8rb61iKLYXjxykdX2qXa9xQLV/iYks6Hh3wYpGQnyiTSR1jDoStfYaU GfC8j8ULznP0b6JKBEojpVnKScw== X-Google-Smtp-Source: AGHT+IFRZNJEmIDWeGq7jBDTWhH6Y05jOZW3+7OggCVpp9D3eKLI+N0SQhYn4TTzkQ07b3SjWfpk0D6PnrkmWhtaNlQ= X-Received: by 2002:a05:6402:4308:b0:5de:5cea:869e with SMTP id 4fb4d7f45d1cf-5de5cea8b38mr8326232a12.32.1739203449824; Mon, 10 Feb 2025 08:04:09 -0800 (PST) MIME-Version: 1.0 References: <20250206132754.2596694-1-rppt@kernel.org> <20250206132754.2596694-14-rppt@kernel.org> In-Reply-To: <20250206132754.2596694-14-rppt@kernel.org> From: Rob Herring Date: Mon, 10 Feb 2025 10:03:58 -0600 X-Gmail-Original-Message-ID: X-Gm-Features: AWEUYZkqxkn1PB0pgkw5chjo9LRqD9SA0TtsGYB7u__vI-ErDb4_rUvPql-Dcx4 Message-ID: Subject: Re: [PATCH v4 13/14] memblock: Add KHO support for reserve_mem To: Mike Rapoport Cc: linux-kernel@vger.kernel.org, Alexander Graf , Andrew Morton , Andy Lutomirski , Anthony Yznaga , Arnd Bergmann , Ashish Kalra , Benjamin Herrenschmidt , Borislav Petkov , Catalin Marinas , Dave Hansen , David Woodhouse , Eric Biederman , Ingo Molnar , James Gowans , Jonathan Corbet , Krzysztof Kozlowski , Mark Rutland , Paolo Bonzini , Pasha Tatashin , "H. Peter Anvin" , Peter Zijlstra , Pratyush Yadav , Saravana Kannan , Stanislav Kinsburskii , Steven Rostedt , Thomas Gleixner , Tom Lendacky , Usama Arif , Will Deacon , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: BB39BC001C X-Stat-Signature: 3ttq9rh76dhqs5ig5q1j6zfdo46d3hbr X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1739203452-201247 X-HE-Meta: U2FsdGVkX1/Jcytc1A7uWmL2p7q2EdYUXmoM3HTRGhZ78Lqw+EBt9yGV7AVTK6GxxYi9A8gUFNjJ2v2/EfX2vpio3z297gR+jM4+zFkhcMg1LGM0KHhCea6C3kgtiMfZaSyJxn3AfVgdo4yWguS1qH/8f34u8zqkJNaxdNBS4OrIKwV1n6lB8lY3JsBkCheePEARjNrA+eaBijGZ7M/+/s6s/WarBWsHTBFbCdJKWIwPDot5FN3US/FPwQspFYxXcUyCBp4rEz9TGQEtJS+FSmyHu0hkMgCXx6QkmBVPkJrbRfg5vsaVktFWt5Jph/uMMGIGKqG0KObojDF4RWVtSHKJkz31PG4TAgDKnKJj1opXid8Rqexn+hMjkCdHBLphj+vZ2j33uxJNWJJXT+8q8DKgxOnMFf/9BfYbRnrgXQaHfxcnZ0IQ4ULnAwr/vldw6li4Kr+B6d7nTqe500ZRpWE+aWWB2jFjWbnuFDk0LK23U+FnGdRcjRIoHBTHx+lbW46Nt4Q7AL6ZQjNtMvrsbDMBHFnsZcPWsN8KqmLl9WIV/zup1xlGjPFD+lMh6bo9BzNRf8AxHvaQ85hCLvKdbwaODHqqaD8Iajc4pqDYvLYoNKIiCPOYJgHOqX2+21iLFW5+Pfw0icW2Q7q6i8I/w47QXL/AENJIf3S2Gp0P53qU2NKW7jzb0WSdlbXKzaDkFdaBeav1ipueY+Ces50Bnahli5E8I0rROpkgmMP501v4vO4BAt05JlQ/ubuh9lsOsQzq70mIW5gVomrvts7/BL/ldMxyKX36vOozNlFdJ1br5VNi/OwmlSULnSvwgP5l6o9YogHlznN5ZprkX53F1c+DKIoZ4bHbpRd7jO3dNEG9haDSNYi0aPNCzNVC5BzIHXVP1XQXe6oQdsK/a2FmD+7dYrrrqCI8P1fUG9dwtpr+xHzLpH0dOUzgEOjIgqgznRnI3QlyogJz2wlRDoY AJhaKZSz Y48Z/g/V9In8Q63DcicVbdr+nw4+tV9BNDKuH+Y6CPfu7rTcdqlGXmVyTk9xrgB5Jo7hDNYCKK39nymkJ+Ry+NasQKYdA/gChCb68Tz2d11NLW/QLV9Z/KLEVFEiksNazR+5305ScwP7z95YLQBHNDDYIlIalKMOuA5L6YMGoIcuMYMsyReOB6XViS+B4DqlkdE5RM1L/5rIL9yQ8Cz+cEhb0CYUIOyS7aNlazP7gli8zyEiOaSq4BdN5xMqOMLLaOJBocTwcISoc4kO0bgpPVKQZomI5j3xsoejCMW6XArRDk9L5gRGR164nV6IqsXBz4iFFcwS1dBDR+jKfl/IXoJolR5+PLe27ds0eBbXo3JKsEhuTGOPGa8J2xZzjRE+e5rfAdWGWu7Dw8FaObFNbgW1sS9hyHfQLHU5e 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 Thu, Feb 6, 2025 at 7:30=E2=80=AFAM Mike Rapoport wrot= e: > > From: Alexander Graf > > Linux has recently gained support for "reserve_mem": A mechanism to > allocate a region of memory early enough in boot that we can cross our > fingers and hope it stays at the same location during most boots, so we > can store for example ftrace buffers into it. > > Thanks to KASLR, we can never be really sure that "reserve_mem" > allocations are static across kexec. Let's teach it KHO awareness so > that it serializes its reservations on kexec exit and deserializes them > again on boot, preserving the exact same mapping across kexec. > > This is an example user for KHO in the KHO patch set to ensure we have > at least one (not very controversial) user in the tree before extending > KHO's use to more subsystems. > > Signed-off-by: Alexander Graf > Co-developed-by: Mike Rapoport (Microsoft) > Signed-off-by: Mike Rapoport (Microsoft) > --- > mm/memblock.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 131 insertions(+) > > diff --git a/mm/memblock.c b/mm/memblock.c > index 84df96efca62..fdb08b60efc1 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -16,6 +16,9 @@ > #include > #include > #include > +#include > +#include > +#include > > #include > #include > @@ -2423,6 +2426,70 @@ int reserve_mem_find_by_name(const char *name, phy= s_addr_t *start, phys_addr_t * > } > EXPORT_SYMBOL_GPL(reserve_mem_find_by_name); > > +static bool __init reserve_mem_kho_revive(const char *name, phys_addr_t = size, > + phys_addr_t align) > +{ > + const void *fdt =3D kho_get_fdt(); > + const char *path =3D "/reserve_mem"; > + int node, child, err; > + > + if (!IS_ENABLED(CONFIG_KEXEC_HANDOVER)) > + return false; > + > + if (!fdt) > + return false; > + > + node =3D fdt_path_offset(fdt, "/reserve_mem"); > + if (node < 0) > + return false; > + > + err =3D fdt_node_check_compatible(fdt, node, "reserve_mem-v1"); > + if (err) { > + pr_warn("Node '%s' has unknown compatible", path); > + return false; > + } > + > + fdt_for_each_subnode(child, fdt, node) { > + const struct kho_mem *mem; > + const char *child_name; > + int len; > + > + /* Search for old kernel's reserved_mem with the same nam= e */ > + child_name =3D fdt_get_name(fdt, child, NULL); > + if (strcmp(name, child_name)) > + continue; > + > + err =3D fdt_node_check_compatible(fdt, child, "reserve_me= m_map-v1"); It really seems you all are trying to have things both ways. It's not Devicetree, just the FDT file format, but then here you use "compatible" which *is* Devicetree. At best, it's all just confusing for folks. At worst, you're just picking and choosing what you want to use. I'm not saying don't use "compatible" just for the sake of looking less like DT, but perhaps your versioning should be done differently. You are reading the 'mem' property straight into a struct. Maybe the struct should have a version. Or the size of the struct is the version much like the userspace ABI is handled for structs. > + if (err) { > + pr_warn("Node '%s/%s' has unknown compatible", pa= th, name); > + continue; > + } > + > + mem =3D fdt_getprop(fdt, child, "mem", &len); > + if (!mem || len !=3D sizeof(*mem)) > + continue; > + > + if (mem->addr & (align - 1)) { It's stated somewhere in this that the FDT data is LE, but here you are assuming the FDT is the same endianness as the CPU not that it's LE. Arm64 can do BE. PowerPC does both. I'm not sure if kexec from one endianness to another is possible. I would guess in theory it is and in practice it's broken already (because kexec is always an afterthought). Either you need to guarantee that native endianness will never be an issue for any arch or you need to make the endianness fixed. Rob