From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
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 086EBC27C53
	for <linux-mm@archiver.kernel.org>; Wed, 12 Jun 2024 07:30:55 +0000 (UTC)
Received: by kanga.kvack.org (Postfix)
	id 819B66B017B; Wed, 12 Jun 2024 03:30:55 -0400 (EDT)
Received: by kanga.kvack.org (Postfix, from userid 40)
	id 7CA7B6B017D; Wed, 12 Jun 2024 03:30:55 -0400 (EDT)
X-Delivered-To: int-list-linux-mm@kvack.org
Received: by kanga.kvack.org (Postfix, from userid 63042)
	id 690DF6B017E; Wed, 12 Jun 2024 03:30:55 -0400 (EDT)
X-Delivered-To: linux-mm@kvack.org
Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10])
	by kanga.kvack.org (Postfix) with ESMTP id 4C3AB6B017B
	for <linux-mm@kvack.org>; Wed, 12 Jun 2024 03:30:55 -0400 (EDT)
Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1])
	by unirelay09.hostedemail.com (Postfix) with ESMTP id E6315801ED
	for <linux-mm@kvack.org>; Wed, 12 Jun 2024 07:30:54 +0000 (UTC)
X-FDA: 82221414828.08.D81C463
Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44])
	by imf03.hostedemail.com (Postfix) with ESMTP id DF39520020
	for <linux-mm@kvack.org>; Wed, 12 Jun 2024 07:30:52 +0000 (UTC)
Authentication-Results: imf03.hostedemail.com;
	dkim=pass header.d=gmail.com header.s=20230601 header.b=Thv9cCK6;
	spf=pass (imf03.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com;
	s=arc-20220608; t=1718177453;
	h=from:from:sender:reply-to: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=JX3oJ82eNeO5bizIMhHP+nlMW1vS5qyRXC4dQHMZXzQ=;
	b=NZzV1qRBLijc7oLI9rZKb3SOq0rNjridC/jxp7ihaMjBnhMLq8PgKq1TtyySbeElinYtrb
	l5GP91KvcRJ2DQso3EVWaYNmLaiPIQMj7DPFI0eIWoAM7Asof3X47Qlutll5WmONviMlXc
	D/bhAAwJkUK7MAkk5o5+u0b9S10qyJY=
ARC-Authentication-Results: i=1;
	imf03.hostedemail.com;
	dkim=pass header.d=gmail.com header.s=20230601 header.b=Thv9cCK6;
	spf=pass (imf03.hostedemail.com: domain of richard.weiyang@gmail.com designates 209.85.208.44 as permitted sender) smtp.mailfrom=richard.weiyang@gmail.com;
	dmarc=pass (policy=none) header.from=gmail.com
ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718177453; a=rsa-sha256;
	cv=none;
	b=Ci7k26RygcE9Pf+GjalYbnBvDkNM6Sx1nl7VwHxmM9xlS4+gH28ouDK7Kq3LeJgDn5Jv4c
	6zvUX95Af0+nRO5hRdebD0jiQ6XEuUMhf00nTMCw4I6dj8UbNRzjHKH0MRsS941bY0sdxj
	eS14CpDBLnk99ubbL1awSQuc7MKHYf8=
Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-572c65cea55so946098a12.0
        for <linux-mm@kvack.org>; Wed, 12 Jun 2024 00:30:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1718177451; x=1718782251; darn=kvack.org;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date
         :message-id:reply-to;
        bh=JX3oJ82eNeO5bizIMhHP+nlMW1vS5qyRXC4dQHMZXzQ=;
        b=Thv9cCK6LpdN75jakFBztfYCbWG4nAfp9zTWmLBDWE3mU5Kah4xE8IoHkVqhxMPpFK
         4zp9AXTWQYEo1boAAEA5OFkOvJdOGdVWSKpz5tAbYEUpv7AUBPUxazjvIjGilUAl1PLA
         u4YTDH8Kb4dvUTzngorvQ6DQq9MlFxwMKGxJQgzXWB1XdPVdJal3pPlaNf5+Aoiqi//v
         +eFxYd5XzPg1Y6SiKbNmaAyqoE4aFB0MPWyF+nsGkKQPxMmv/KdDG8WnNcKLp9nojAv7
         dt1Sn3PDDPnKvSyFM+Hwxshxp0HVYAZCa6fczk19xEQQO38nixuF5jvuojFCWOOYPGcM
         Ybuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1718177451; x=1718782251;
        h=user-agent:in-reply-to:content-disposition:mime-version:references
         :reply-to:message-id:subject:cc:to:from:date:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=JX3oJ82eNeO5bizIMhHP+nlMW1vS5qyRXC4dQHMZXzQ=;
        b=W8snBVhKu4LmJQgpJT3sNT3w9DEVivBWqp/i+s9oNfRt0vCHoErdkgA7z+YIVTU77x
         Y0qz5C2CGKv1EoQKSnz+nFh1d8a53TgagQpJFgKYCFjWERduUDnG4/b2+LamdSE/4iiE
         joNbSkOR8GVKkjoAjfnae8uj4RimQo2+3mVm55wyPhdnLjbE+zyROmaSMSm46sPJFa1p
         TsaSrpNSMtDCJ3CEaXgPKphYI8IH7XtEzD7K1XIQl8qbncYUBBkHiX8lwrTwLDoAJyfB
         b7T+CnHYnsjt+e9g/PhSts0V8t46SN8HJhnQEy8+K30/zDSOQUStOCnvFSZ62JOENygY
         c6FQ==
X-Forwarded-Encrypted: i=1; AJvYcCWFN4sFtdD4UBahkuCdMgd2vg/aZMCFc44B7ZsaPKFUYav/MhwOMQequfTg+iA/JnyOcEVuMGHbVlo3BFu/TYhsX6g=
X-Gm-Message-State: AOJu0Yzl17OKeMduamfrEPv6sMJieEX+N8oRA+nlhmS4KxnR96VZwp8r
	VuxvxjjqpMzN76K/5P6FBDR3b+24QyqcPMkfHou6k5/V4GvdiFxJ
X-Google-Smtp-Source: AGHT+IH10d8wKZW7QVcduV/RLxAQsP/7llA3XpbI+F3SWl6OF6LKMYpTn+arhdpnxgG7EWeXdwdKug==
X-Received: by 2002:a05:6402:791:b0:578:6360:aa11 with SMTP id 4fb4d7f45d1cf-57c90a228admr3208454a12.5.1718177451021;
        Wed, 12 Jun 2024 00:30:51 -0700 (PDT)
Received: from localhost ([185.92.221.13])
        by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57c874e3cb6sm4006384a12.27.2024.06.12.00.30.50
        (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256);
        Wed, 12 Jun 2024 00:30:50 -0700 (PDT)
Date: Wed, 12 Jun 2024 07:30:49 +0000
From: Wei Yang <richard.weiyang@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Lorenzo Stoakes <lstoakes@gmail.com>, linux-mm@kvack.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Kees Cook <keescook@chromium.org>, Tony Luck <tony.luck@intel.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	linux-hardening@vger.kernel.org, Guenter Roeck <linux@roeck-us.net>,
	Ross Zwisler <zwisler@google.com>, wklin@google.com,
	Vineeth Remanan Pillai <vineeth@bitbyteword.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Suleiman Souhlal <suleiman@google.com>,
	Linus Torvalds <torvalds@linuxfoundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v2 1/2] mm/memblock: Add "reserve_mem" to reserved named
 memory at boot up
Message-ID: <20240612073049.xof3ciae2x5qjp6a@master>
Reply-To: Wei Yang <richard.weiyang@gmail.com>
References: <20240606150143.876469296@goodmis.org>
 <20240606150316.751642266@goodmis.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240606150316.751642266@goodmis.org>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Rspam-User: 
X-Rspamd-Server: rspam02
X-Rspamd-Queue-Id: DF39520020
X-Stat-Signature: zhptfk7hfp6ob8rgyy1y5pxtbb7usk19
X-HE-Tag: 1718177452-582329
X-HE-Meta: U2FsdGVkX1/JfeOTX8WtivAgQiyfTDC1RMV1CIDQej01kmyx4gE3ZAiMlLC3mYVEKnLU6RfKUY/iLxBh5fAIMNlIqYQCAxwIn6kmU2i7ULUlMuyojrCphmyV4i4hbyh9g9I9s1nhiHKSb1PUUzTt9opDasplSiHHNoswhCb5/47hoWMYxCYEkd4hP5qpYxtDOUR47ODmuOROqk/+jL9szgmL0+KJr3SqsCk+GoSdQ4leioHne+72bW0/WpM89n7eb4O5XpkGkRym/Qzo1WWIKNo5Sqfertw+/rmI489frGuykGetkpmeyTrEwdeo5Ta16xQBuhNFzlusnCSFeAel/N0HMt8ty6DVRZXN9DaIN4C5F4pnm0tWoOpqv48CsVbLTFAylCREHW8X9XA3EBq79XQwSoyrGZU8YoYVRloIYulV43UrophaTeCMThMAyDhix6d63IkpuqJ/WCztK1Bq6Kr0YDBx8jyos/rPKDEAkXPLGz6cXSjKpnh+PMQR3um9g2sScBkw1AjB3EwZpM3PB0qoIcRh0BSkjvHYjh4EiwWF/xZqben5bzcfmdS7VOz4VZ+bxjAQYxRtNCfI6p7QoEAXSBYCksHmTdGx0QywLrRea1bM+AZZwgrZtrqAxRpo1vmVLQR7n4/lipTIeXYy4h/DdlEJ8z9iMliAE02xF+ac7JirRgUIjrThtX8m1t781divwiuNiXv+BOlxLVJy1Prag81QdKDZHUZ1wN8zvPZxqcJxMeftnb5Wsgw+0g+wgmwmBbTN72PkQnQ5qJYICgr0jwZgaJKIRlgHKUHjYGf0o1U+cdNnOZBczegVaPHfdVKO0MQ2rrjj/w1AhjLAwsbZGr/xDt5mMyoyOvMd2kdvZE/ZlTJK+PYyo+9/0kMXgO0Y8CHK7CibGrPYBCvZqPrkgH+/wVLDltxhe+VE8Wo0RimSAU+WvWo2eIzPuAu1guQXM/SdtYsJqvAnspC
 R5f7isHC
 ftBqlOaK6dLjXsSubfQZCfafIhb2lx8AZhAIPdN3ZUYP9zaVr3kJ0tIkVCrPRVOcYlQ+ewjD8H5X/27ZfFrZxv36kHuWMFhFhrL/YmF4GSV6P1UiZWv3gv+OQ9dVL60mLam5XrPnlHQsAn/01ZOqSYg3W6QYg2PDOkmeOspga2zjW2AjDsEUkU6A3yvHnhL76oMLYA4wT27RL1mkXG7GtO6kV+CUklLVoQEJ1o6Ft8He008Y/JIp9xAueEueMBAVqcoNzrJRQ+5P1vDYzRuWF97FB+GHuaSbO2OxmGyr6tTaOWJjr+BdMpHWtLBOvCCAyzmAJQsun9EQ7oAEbEoQ9CriXLNDkgMJ530OPf1ATD97pY84H2upU6iPNWPE176bFLA1lvAuxfIbWKONYCmb4l3N0P3ZgPn+RYdeRyK4agDEwv9L7YS+l06fAk7Dg/KDZGvJ0fD3VTWYy1Y3SkiFgd7C6NrN2/1om7hJg0S9ErdYmdWvNJA7qToJXUCxyfSlfEfgu7CYhFPHqnHtdI/vzDWvF4TLNIltMg0u9afAl0NbLqUtbchdkfFXf7XS4EKLpK/6LP2ST16XLPSbOeL/sec2NowgQOdExIoIX7uah3mENyrmzLq79P3FT/xkIi0rja/tTycUoCFc8mFiQy6FfzqYdaE5KhJbiVWFq0h+DHNBgqHuch+kQ/Y/2kyIyF5fY/wiU
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: <linux-mm.kvack.org>
List-Subscribe: <mailto:majordomo@kvack.org>
List-Unsubscribe: <mailto:majordomo@kvack.org>

On Thu, Jun 06, 2024 at 11:01:44AM -0400, Steven Rostedt wrote:
>From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
>
>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 <rppt@kernel.org>
>Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
>---
> .../admin-guide/kernel-parameters.txt         | 20 ++++
> include/linux/mm.h                            |  2 +
> mm/memblock.c                                 | 97 +++++++++++++++++++
> 3 files changed, 119 insertions(+)
>
>diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>index b600df82669d..4b2f7fb8de66 100644
>--- a/Documentation/admin-guide/kernel-parameters.txt
>+++ b/Documentation/admin-guide/kernel-parameters.txt
>@@ -5710,6 +5710,26 @@
> 			them.  If <base> is less than 0x10000, the region
> 			is assumed to be I/O ports; otherwise it is memory.
> 
>+	reserve_mem=	[RAM]
>+			Format: nn[KNG]:<align>:<label>
>+			Reserve physical memory and label it with a name that
>+			other subsystems can use to access it. 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.
>+
>+			The format is size:align:label for example, to request
>+			12 megabytes of 4096 alignment for ramoops:
>+
>+			reserver_mem=12M:4096:oops ramoops.mem_name=oops
>+
> 	reservetop=	[X86-32,EARLY]
> 			Format: nn[KMG]
> 			Reserves a hole at the top of the kernel virtual
>diff --git a/include/linux/mm.h b/include/linux/mm.h
>index 9849dfda44d4..b4455cc02f2c 100644
>--- a/include/linux/mm.h
>+++ b/include/linux/mm.h
>@@ -4263,4 +4263,6 @@ static inline bool pfn_is_unaccepted_memory(unsigned long pfn)
> void vma_pgtable_walk_begin(struct vm_area_struct *vma);
> void vma_pgtable_walk_end(struct vm_area_struct *vma);
> 
>+int reserve_mem_find_by_name(const char *name, unsigned long *start, unsigned long *size);
>+
> #endif /* _LINUX_MM_H */
>diff --git a/mm/memblock.c b/mm/memblock.c
>index d09136e040d3..a8bf0ee9e2b4 100644
>--- a/mm/memblock.c
>+++ b/mm/memblock.c
>@@ -2244,6 +2244,103 @@ void __init memblock_free_all(void)
> 	totalram_pages_add(pages);
> }
> 
>+/* Keep a table to reserve named memory */
>+#define RESERVE_MEM_MAX_ENTRIES		8
>+#define RESERVE_MEM_NAME_SIZE		16
>+struct reserve_mem_table {
>+	char			name[RESERVE_MEM_NAME_SIZE];
>+	unsigned long		start;
>+	unsigned long		size;
>+};
>+static struct reserve_mem_table reserved_mem_table[RESERVE_MEM_MAX_ENTRIES];
>+static int reserved_mem_count;
>+
>+/* Add wildcard region with a lookup name */
>+static int __init reserved_mem_add(unsigned long start, unsigned long size,
>+				   const char *name)
>+{
>+	struct reserve_mem_table *map;
>+
>+	if (!name || !name[0] || strlen(name) >= RESERVE_MEM_NAME_SIZE)
>+		return -EINVAL;
>+
>+	if (reserved_mem_count >= RESERVE_MEM_MAX_ENTRIES)
>+		return -1;

Another thing come to my mind: could we specify several reserve_mem on the
command line?

If so, we may need to check whether names conflict.

>+
>+	map = &reserved_mem_table[reserved_mem_count++];
>+	map->start = start;
>+	map->size = size;
>+	strscpy(map->name, name);
>+	return 0;
>+}
>+
>+/**
>+ * reserve_mem_find_by_name - Find reserved memory region with a given name
>+ * @name: The name that is attached to a reserved memory region
>+ * @start: If found, holds the start address
>+ * @size: If found, holds the size of the address.
>+ *
>+ * Returns: 1 if found or 0 if not found.
>+ */
>+int reserve_mem_find_by_name(const char *name, unsigned long *start, unsigned long *size)
>+{
>+	struct reserve_mem_table *map;
>+	int i;
>+
>+	for (i = 0; i < reserved_mem_count; i++) {
>+		map = &reserved_mem_table[i];
>+		if (!map->size)
>+			continue;
>+		if (strcmp(name, map->name) == 0) {
>+			*start = map->start;
>+			*size = map->size;
>+			return 1;
>+		}
>+	}
>+	return 0;
>+}
>+
>+/*
>+ * Parse early_reserve_mem=nn:align:name
>+ */
>+static int __init reserve_mem(char *p)
>+{
>+	phys_addr_t start, size, align;
>+	char *oldp;
>+	int err;
>+
>+	if (!p)
>+		return -EINVAL;
>+
>+	oldp = p;
>+	size = memparse(p, &p);
>+	if (p == oldp)
>+		return -EINVAL;
>+
>+	if (*p != ':')
>+		return -EINVAL;
>+
>+	align = memparse(p+1, &p);
>+	if (*p != ':')
>+		return -EINVAL;
>+
>+	start = memblock_phys_alloc(size, align);
>+	if (!start)
>+		return -ENOMEM;
>+
>+	p++;
>+	err = reserved_mem_add(start, size, p);
>+	if (err) {
>+		memblock_phys_free(start, size);
>+		return err;
>+	}
>+
>+	p += strlen(p);
>+
>+	return *p == '\0' ? 0: -EINVAL;
>+}
>+__setup("reserve_mem=", reserve_mem);
>+
> #if defined(CONFIG_DEBUG_FS) && defined(CONFIG_ARCH_KEEP_MEMBLOCK)
> static const char * const flagname[] = {
> 	[ilog2(MEMBLOCK_HOTPLUG)] = "HOTPLUG",
>-- 
>2.43.0
>
>

-- 
Wei Yang
Help you, Help me