From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (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 9983422E3E7; Thu, 11 Dec 2025 02:53:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765421604; cv=none; b=VOxDgFGufU3PcW3IQfEEjJj9kOqct4oxMFfrX8WYt7ZYRbN9tGv1FGkSuJf81Kr7Vrhvb1Doechk50l0MgyiRpP5tG/4LS/aEUuUH0FNlIMUrUU25llVLBTJRNIdS1gcbQonVzUOjBnIG0A+K0c2GccsUyWvw2PtGjtO8Hev104= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765421604; c=relaxed/simple; bh=nCP4Qrkpz8bVZqCHE4sJmyUXXrSPtXg/5yZwtOzX+cg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LJwa9fcIIHJr4TX2OwvOcftrXJpV7nSw+zssjGaqAMZcDh5yRafFVcYnbb0MEI2NdSFs+nT7xBMfWohv4Gd6Lu3AW3rt5qlF+1E4Fn8X2qAuGhkSGsdfCzXn6Dy4xxhDFc9UM68I9K4iNks/YZlmGb32VOnrN9sWLOskuektdgU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=MpAmoqOo; arc=none smtp.client-ip=192.198.163.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="MpAmoqOo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1765421602; x=1796957602; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=nCP4Qrkpz8bVZqCHE4sJmyUXXrSPtXg/5yZwtOzX+cg=; b=MpAmoqOoHGZysuAML7Y+wd/q3kaq00LLRezMvmqNtJ+kXENeIbykF2RW x7ZwpzNuyNcpH/GLOGEjGl0di3xTetAWpOz79RzILU55Uh+ZVkM1Rykl3 R7ePJ42Uki5NhKirq8/a5Wx0l/kMrH7fU/NC7U3CAcQqLqK7/4seSelH/ anlvleuu8UZ2T4FQLIpN22fFb3A/QF9Fbzl4iA1XIjOc1KLKp+Sfpv97c do9J0LTJ2s2PlkfHLn8biQ0CnO6ybuqKEd3o49m6WrH0KzBed2ZUhxDhF 89gfc3J8sBBTpLclwOPSNsG9f1OjiQFNWvlhOuluWWNKeW9ksHRr8EChk Q==; X-CSE-ConnectionGUID: nS78aV6CQ1CVgJzDracwRA== X-CSE-MsgGUID: MQn3uHaWTAGbSeXkAg41GA== X-IronPort-AV: E=McAfee;i="6800,10657,11638"; a="78765557" X-IronPort-AV: E=Sophos;i="6.20,265,1758610800"; d="scan'208";a="78765557" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Dec 2025 18:53:20 -0800 X-CSE-ConnectionGUID: Zev6oIoBRpaOqU2xDpbw4g== X-CSE-MsgGUID: oROrgDILQmSBZQ6XsbXTuA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.20,265,1758610800"; d="scan'208";a="196738003" Received: from ranerica-svr.sc.intel.com ([172.25.110.23]) by orviesa008.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Dec 2025 18:53:20 -0800 Date: Wed, 10 Dec 2025 19:00:06 -0800 From: Ricardo Neri To: Changyuan Lyu , "Mike Rapoport (Microsoft)" Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, anthony.yznaga@oracle.com, arnd@arndb.de, ashish.kalra@amd.com, benh@kernel.crashing.org, bp@alien8.de, catalin.marinas@arm.com, corbet@lwn.net, dave.hansen@linux.intel.com, devicetree@vger.kernel.org, dwmw2@infradead.org, ebiederm@xmission.com, graf@amazon.com, hpa@zytor.com, jgowans@amazon.com, kexec@lists.infradead.org, krzk@kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, luto@kernel.org, mark.rutland@arm.com, mingo@redhat.com, pasha.tatashin@soleen.com, pbonzini@redhat.com, peterz@infradead.org, ptyadav@amazon.de, robh@kernel.org, rostedt@goodmis.org, rppt@kernel.org, saravanak@google.com, skinsburskii@linux.microsoft.com, tglx@linutronix.de, thomas.lendacky@amd.com, will@kernel.org, x86@kernel.org Subject: Re: [PATCH v8 17/17] Documentation: KHO: Add memblock bindings Message-ID: <20251211030006.GA9333@ranerica-svr.sc.intel.com> References: <20250509074635.3187114-1-changyuanl@google.com> <20250509074635.3187114-18-changyuanl@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250509074635.3187114-18-changyuanl@google.com> User-Agent: Mutt/1.9.4 (2018-02-28) On Fri, May 09, 2025 at 12:46:35AM -0700, Changyuan Lyu wrote: > From: "Mike Rapoport (Microsoft)" > > We introduced KHO into Linux: A framework that allows Linux to pass > metadata and memory across kexec from Linux to Linux. KHO reuses fdt > as file format and shares a lot of the same properties of firmware-to- > Linux boot formats: It needs a stable, documented ABI that allows for > forward and backward compatibility as well as versioning. > > As first user of KHO, we introduced memblock which can now preserve > memory ranges reserved with reserve_mem command line options contents > across kexec, so you can use the post-kexec kernel to read traces from > the pre-kexec kernel. > > This patch adds memblock schemas similar to "device" device tree ones to > a new kho bindings directory. This allows us to force contributors to > document the data that moves across KHO kexecs and catch breaking change > during review. > > Co-developed-by: Alexander Graf > Signed-off-by: Alexander Graf > Signed-off-by: Mike Rapoport (Microsoft) > Signed-off-by: Changyuan Lyu > --- > .../kho/bindings/memblock/memblock.yaml | 39 ++++++++++++++++++ > .../kho/bindings/memblock/reserve-mem.yaml | 40 +++++++++++++++++++ > MAINTAINERS | 1 + > 3 files changed, 80 insertions(+) > create mode 100644 Documentation/core-api/kho/bindings/memblock/memblock.yaml > create mode 100644 Documentation/core-api/kho/bindings/memblock/reserve-mem.yaml > > diff --git a/Documentation/core-api/kho/bindings/memblock/memblock.yaml b/Documentation/core-api/kho/bindings/memblock/memblock.yaml > new file mode 100644 > index 0000000000000..d388c28eb91d1 > --- /dev/null > +++ b/Documentation/core-api/kho/bindings/memblock/memblock.yaml > @@ -0,0 +1,39 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +title: Memblock reserved memory > + > +maintainers: > + - Mike Rapoport > + > +description: | > + Memblock can serialize its current memory reservations created with > + reserve_mem command line option across kexec through KHO. > + The post-KHO kernel can then consume these reservations and they are > + guaranteed to have the same physical address. Hi Changyuan, Mike, I am sorry I am late to this patchset. I am working on a patchset to use KHO to pass reserved memory regions to a driver after kexec and I have a few questions. > + > +properties: > + compatible: > + enum: > + - reserve-mem-v1 Shouldn't this be "memblock-v1". IIUC, the compatible "reserve-mem-v1" is to be used for the memblock reserved memory regions, not the memblock node. > + > +patternProperties: > + "$[0-9a-f_]+^": Shouldn't this be "^[0-9a-f_]+$": ^ at the start of the pattern and $ at the end of it? Or is this a KHO-specific rule? Also, IIUC, this means that names of the nodes are hexadecimal numbers whereas the example below has a "membloc" name. I assume this does not refer to the subnode named "n1" as this does not follow the pattern either Moreover, it should have been documented in the reserve-mem binding. > + $ref: reserve-mem.yaml# > + description: reserved memory regions > + > +required: > + - compatible > + > +additionalProperties: false > + > +examples: > + - | > + memblock { > + compatible = "memblock-v1"; > + n1 { > + compatible = "reserve-mem-v1"; > + start = <0xc06b 0x4000000>; > + size = <0x04 0x00>; > + }; > + }; Thanks and BR, Ricardo