From patchwork Thu Jun 13 00:34:36 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Rostedt X-Patchwork-Id: 13695711 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E85F63A5; Thu, 13 Jun 2024 00:34:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718238893; cv=none; b=an4CZBk4rnrtxPHWg5yEYJo9wY7lvvDKS/pIa4PZbI5NnsSalqoo2nF5Sw6mTaFFV237AJWWkMffoX3wsFmJ5s3Y8w7NLW76DeM2FsbIsfYa1l5ME7xYCoqwcgKCC8t3ZGEKSUHVfrNDYEqWAfbvhNHxUgz+6A1YmxolQW8edNE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718238893; c=relaxed/simple; bh=uhP9G8bT8fUmRQ2ghs8UzgPprc3W3L4JLL0dPpaSGH8=; h=Message-ID:Date:From:To:Cc:Subject:References:MIME-Version: Content-Type; b=IjJswwRxQ4PomoJjTaOJ0AcbM2fzrJpZ2pBPhdOQlJrRVAyv/5hsjVU1vN/Zuc3KdiVZom9R5aEh9fq+TuUNe1HLZ5afheOMglL9aQV2g6phMTtShxAB7GfdJoQ9bCzeLNaUe6dnPSvmNt4kyXAEavgOhy5kfnYpGjV2PjYZxDk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95BCCC32786; Thu, 13 Jun 2024 00:34:52 +0000 (UTC) Received: from rostedt by gandalf with local (Exim 4.97) (envelope-from ) id 1sHYQm-00000001eN3-3lZi; Wed, 12 Jun 2024 20:35:08 -0400 Message-ID: <20240613003508.752963299@goodmis.org> User-Agent: quilt/0.68 Date: Wed, 12 Jun 2024 20:34:36 -0400 From: Steven Rostedt To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org Cc: Masami Hiramatsu , Mark Rutland , Mathieu Desnoyers , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , linux-mm@kvack.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Kees Cook , Tony Luck , "Guilherme G. Piccoli" , linux-hardening@vger.kernel.org, Guenter Roeck , Ross Zwisler , wklin@google.com, Vineeth Remanan Pillai , Joel Fernandes , Suleiman Souhlal , Linus Torvalds , Catalin Marinas , Will Deacon , Ard Biesheuvel , Mike Rapoport Subject: [PATCH v5 1/2] mm/memblock: Add "reserve_mem" to reserved named memory at boot up References: <20240613003435.401549779@goodmis.org> Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: "Steven Rostedt (Google)" In order to allow for requesting a memory region that can be used for things like pstore on multiple machines where the memory layout is not the same, add a new option to the kernel command line called "reserve_mem". The format is: reserve_mem=nn:align:name Where it will find nn amount of memory at the given alignment of align. The name field is to allow another subsystem to retrieve where the memory was found. For example: reserve_mem=12M:4096:oops ramoops.mem_name=oops Where ramoops.mem_name will tell ramoops that memory was reserved for it via the reserve_mem option and it can find it by calling: if (reserve_mem_find_by_name("oops", &start, &size)) { // start holds the start address and size holds the size given This is typically used for systems that do not wipe the RAM, and this command line will try to reserve the same physical memory on soft reboots. Note, it is not guaranteed to be the same location. For example, if KASLR places the kernel at the location of where the RAM reservation was from a previous boot, the new reservation will be at a different location. Any subsystem using this feature must add a way to verify that the contents of the physical memory is from a previous boot, as there may be cases where the memory will not be located at the same location. Not all systems may work either. There could be bit flips if the reboot goes through the BIOS. Using kexec to reboot the machine is likely to have better results in such cases. Link: https://lore.kernel.org/all/ZjJVnZUX3NZiGW6q@kernel.org/ Suggested-by: Mike Rapoport Tested-by: Guilherme G. Piccoli Signed-off-by: Steven Rostedt (Google) --- Changes since v4: https://lore.kernel.org/linux-trace-kernel/20240611215801.443593152@goodmis.org - Add all checks about reserve_mem before allocation. This means reserved_mem_add() is now a void function. - Check for name duplications. - Fix compare of align to SMP_CACHE_BYTES ("<" instead of "<=") .../admin-guide/kernel-parameters.txt | 20 +++ include/linux/mm.h | 2 + mm/memblock.c | 117 ++++++++++++++++++ 3 files changed, 139 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index b600df82669d..ce7de8136f2f 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -5710,6 +5710,26 @@ them. If is less than 0x10000, the region is assumed to be I/O ports; otherwise it is memory. + reserve_mem= [RAM] + Format: nn[KNG]::