lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45df0d7a-622a-4268-9683-c5c6067483c3@kernel.org>
Date: Sun, 9 Feb 2025 11:29:41 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Mike Rapoport <rppt@...nel.org>, linux-kernel@...r.kernel.org
Cc: Alexander Graf <graf@...zon.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Andy Lutomirski
 <luto@...nel.org>, Anthony Yznaga <anthony.yznaga@...cle.com>,
 Arnd Bergmann <arnd@...db.de>, Ashish Kalra <ashish.kalra@....com>,
 Benjamin Herrenschmidt <benh@...nel.crashing.org>,
 Borislav Petkov <bp@...en8.de>, Catalin Marinas <catalin.marinas@....com>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 David Woodhouse <dwmw2@...radead.org>, Eric Biederman
 <ebiederm@...ssion.com>, Ingo Molnar <mingo@...hat.com>,
 James Gowans <jgowans@...zon.com>, Jonathan Corbet <corbet@....net>,
 Mark Rutland <mark.rutland@....com>, Paolo Bonzini <pbonzini@...hat.com>,
 Pasha Tatashin <pasha.tatashin@...een.com>, "H. Peter Anvin"
 <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>,
 Pratyush Yadav <ptyadav@...zon.de>, Rob Herring <robh+dt@...nel.org>,
 Rob Herring <robh@...nel.org>, Saravana Kannan <saravanak@...gle.com>,
 Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>,
 Steven Rostedt <rostedt@...dmis.org>, Thomas Gleixner <tglx@...utronix.de>,
 Tom Lendacky <thomas.lendacky@....com>, Usama Arif
 <usama.arif@...edance.com>, Will Deacon <will@...nel.org>,
 devicetree@...r.kernel.org, kexec@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
 linux-mm@...ck.org, x86@...nel.org
Subject: Re: [PATCH v4 14/14] Documentation: KHO: Add memblock bindings

On 06/02/2025 14:27, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)" <rppt@...nel.org>
> 
> 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.

Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching. For bindings, the preferred subjects are
explained here:
https://www.kernel.org/doc/html/latest/devicetree/bindings/submitting-patches.html#i-for-patch-submitters


> 
> 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 <graf@...zon.com>
> Signed-off-by: Alexander Graf <graf@...zon.com>
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@...nel.org>
> ---
>  .../kho/bindings/memblock/reserve_mem.yaml    | 41 ++++++++++++++++++
>  .../bindings/memblock/reserve_mem_map.yaml    | 42 +++++++++++++++++++
>  2 files changed, 83 insertions(+)
>  create mode 100644 Documentation/kho/bindings/memblock/reserve_mem.yaml
>  create mode 100644 Documentation/kho/bindings/memblock/reserve_mem_map.yaml
> 
> diff --git a/Documentation/kho/bindings/memblock/reserve_mem.yaml b/Documentation/kho/bindings/memblock/reserve_mem.yaml
> new file mode 100644
> index 000000000000..7b01791b10b3
> --- /dev/null
> +++ b/Documentation/kho/bindings/memblock/reserve_mem.yaml
> @@ -0,0 +1,41 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memblock/reserve_mem.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Memblock reserved memory
> +
> +maintainers:
> +  - Mike Rapoport <rppt@...nel.org>
> +
> +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.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - reserve_mem-v1

NAK, underscores are not allowed. Please follow carefully DTS coding style.

> +
> +patternProperties:
> +  "$[0-9a-f_]+^":

No underscores.

> +    $ref: reserve_mem_map.yaml#
> +    description: reserved memory regions
> +
> +required:
> +  - compatible
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    reserve_mem {

Again, do not introduce own coding style.

I don't understand why do you need this in the first place. There is
already reserved-memory block.


> +      compatible = "reserve_mem-v1";
> +        r1 {
> +          compatible = "reserve_mem_map-v1";
> +          mem = <0xc07c 0x2000000 0x01 0x00>;
> +        };
> +    };
> diff --git a/Documentation/kho/bindings/memblock/reserve_mem_map.yaml b/Documentation/kho/bindings/memblock/reserve_mem_map.yaml
> new file mode 100644
> index 000000000000..09001c5f2124
> --- /dev/null
> +++ b/Documentation/kho/bindings/memblock/reserve_mem_map.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memblock/reserve_mem_map.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Memblock reserved memory regions
> +
> +maintainers:
> +  - Mike Rapoport <rppt@...nel.org>
> +
> +description: |
> +  Memblock can serialize its current memory reservations created with
> +  reserve_mem command line option across kexec through KHO.
> +  This object describes each such region.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - reserve_mem_map-v1

Explain why you cannot use existing reserved memory bindings.


Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ