From: Rob Herring <robh@kernel.org>
To: Alexander Graf <graf@amazon.com>
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-mm@kvack.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kexec@lists.infradead.org,
linux-doc@vger.kernel.org, x86@kernel.org,
Eric Biederman <ebiederm@xmission.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Ashish Kalra <ashish.kalra@amd.com>,
James Gowans <jgowans@amazon.com>,
Stanislav Kinsburskii <skinsburskii@linux.microsoft.com>,
arnd@arndb.de, pbonzini@redhat.com, madvenka@linux.microsoft.com,
Anthony Yznaga <anthony.yznaga@oracle.com>,
Usama Arif <usama.arif@bytedance.com>,
David Woodhouse <dwmw@amazon.co.uk>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO
Date: Tue, 2 Jan 2024 08:20:23 -0700 [thread overview]
Message-ID: <20240102152023.GA2821956-robh@kernel.org> (raw)
In-Reply-To: <20231222195144.24532-12-graf@amazon.com>
On Fri, Dec 22, 2023 at 07:51:44PM +0000, Alexander Graf wrote:
> With ftrace in KHO, we are creating an ABI between old kernel and new
> kernel about the state that they transfer. To ensure that we document
> that state and catch any breaking change, let's add its schema to the
> common devicetree bindings. This way, we can quickly reason about the
> state that gets passed.
Why so much data in DT rather than putting all this information into
memory in your own data structure and DT just has a single property
pointing to that? That's what is done with every other blob of data
passed by kexec.
>
> Signed-off-by: Alexander Graf <graf@amazon.com>
> ---
> .../bindings/kho/ftrace/ftrace-array.yaml | 46 +++++++++++++++
> .../bindings/kho/ftrace/ftrace-cpu.yaml | 56 +++++++++++++++++++
> .../bindings/kho/ftrace/ftrace.yaml | 48 ++++++++++++++++
> 3 files changed, 150 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> create mode 100644 Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
>
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> new file mode 100644
> index 000000000000..9960fefc292d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-array.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-array.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace trace array
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace,array-v1
> +
> + trace_flags:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Bitmap of all the trace flags that were enabled in the trace array at the
> + point of serialization.
> +
> +# Subnodes will be of type "ftrace,cpu-v1", one each per CPU
This can be expressed as a schema.
> +additionalProperties: true
> +
> +required:
> + - compatible
> + - trace_flags
> +
> +examples:
> + - |
> + ftrace {
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> new file mode 100644
> index 000000000000..58c715e93f37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace-cpu.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace-cpu.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace per-CPU ring buffer contents
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace,cpu-v1
> +
> + cpu:
> + $ref: /schemas/types.yaml#/definitions/uint32
'cpu' is already a defined property of type 'phandle'. While we can have
multiple types for a given property name, best practice is to avoid
that. The normal way to refer to a CPU would be a phandle to the CPU
node, but I can see that might not make sense here.
"CPU numbers" on arm64 are 64-bit values as well as they are the
CPU's MPIDR value.
> + description:
> + CPU number of the CPU that this ring buffer belonged to when it was
> + serialized.
> +
> + mem:
Too vague. Make the property name indicate what's in the memory.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Array of { u64 phys_addr, u64 len } elements that describe a list of ring
> + buffer pages. Each page consists of two elements. The first element
> + describes the location of the struct buffer_page that contains metadata
> + for a given ring buffer page, such as the ring's head indicator. The
> + second element points to the ring buffer data page which contains the raw
> + trace data.
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - cpu
> + - mem
> +
> +examples:
> + - |
> + ftrace {
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> new file mode 100644
> index 000000000000..b87a64843af3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/kho/ftrace/ftrace.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/kho/ftrace/ftrace.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ftrace core data
> +
> +maintainers:
> + - Alexander Graf <graf@amazon.com>
> +
> +properties:
> + compatible:
> + enum:
> + - ftrace-v1
> +
> + events:
Again, too vague.
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Array of { u32 crc, u32 type } elements. Each element contains a unique
> + identifier for an event, followed by the identifier that this event had
> + in the previous kernel's trace buffers.
> +
> +# Other child nodes will be of type "ftrace,array-v1". Each of which describe
> +# a trace buffer
> +additionalProperties: true
> +
> +required:
> + - compatible
> + - events
> +
> +examples:
> + - |
> + ftrace {
This should go under /chosen. Show that here. Start the example with
'/{' to do that and not add the usual boilerplate we add when extracting
the examples.
Also, we don't need 3 examples. Just do 1 complete example here.
> + compatible = "ftrace-v1";
> + events = <1 1 2 2 3 3>;
> +
> + global_trace {
> + compatible = "ftrace,array-v1";
> + trace_flags = < 0x3354601 >;
> +
> + cpu0 {
> + compatible = "ftrace,cpu-v1";
> + cpu = < 0x00 >;
> + mem = < 0x101000000ULL 0x38ULL 0x101000100ULL 0x1000ULL 0x101000038ULL 0x38ULL 0x101002000ULL 0x1000ULL>;
> + };
> + };
> + };
> --
> 2.40.1
>
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
>
>
>
next prev parent reply other threads:[~2024-01-02 15:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-22 19:35 [PATCH v2 00/17] kexec: Allow preservation of ftrace buffers Alexander Graf
2023-12-22 19:35 ` [PATCH v2 01/17] mm,memblock: Add support for scratch memory Alexander Graf
2023-12-22 19:35 ` [PATCH v2 02/17] memblock: Declare scratch memory as CMA Alexander Graf
2024-01-01 3:01 ` Stanislav Kinsburskii
2023-12-22 19:35 ` [PATCH v2 03/17] kexec: Add Kexec HandOver (KHO) generation helpers Alexander Graf
2023-12-22 19:35 ` [PATCH v2 04/17] kexec: Add KHO parsing support Alexander Graf
2024-01-01 3:33 ` Stanislav Kinsburskii
2024-01-15 13:27 ` Alexander Graf
2023-12-22 19:35 ` [PATCH v2 05/17] kexec: Add KHO support to kexec file loads Alexander Graf
2023-12-22 19:35 ` [PATCH v2 06/17] kexec: Add config option for KHO Alexander Graf
2023-12-22 19:35 ` [PATCH v2 07/17] kexec: Add documentation " Alexander Graf
2024-01-01 3:55 ` Stanislav Kinsburskii
2023-12-22 19:35 ` [PATCH v2 08/17] arm64: Add KHO support Alexander Graf
2023-12-22 19:35 ` [PATCH v2 09/17] x86: " Alexander Graf
2023-12-22 19:36 ` [PATCH v2 10/17] tracing: Initialize fields before registering Alexander Graf
2023-12-22 19:36 ` [PATCH v2 11/17] tracing: Introduce kho serialization Alexander Graf
2023-12-22 19:51 ` [PATCH v2 06/17] kexec: Add config option for KHO Alexander Graf
2023-12-22 19:51 ` [PATCH v2 07/17] kexec: Add documentation " Alexander Graf
2024-01-03 18:48 ` Rob Herring
2024-01-17 14:01 ` Alexander Graf
2024-01-17 16:54 ` Rob Herring
2024-01-17 17:00 ` Alexander Graf
2023-12-22 19:51 ` [PATCH v2 08/17] arm64: Add KHO support Alexander Graf
2023-12-22 19:51 ` [PATCH v2 09/17] x86: " Alexander Graf
2023-12-22 19:51 ` [PATCH v2 10/17] tracing: Initialize fields before registering Alexander Graf
2023-12-22 19:51 ` [PATCH v2 11/17] tracing: Introduce kho serialization Alexander Graf
2023-12-22 19:51 ` [PATCH v2 12/17] tracing: Add kho serialization of trace buffers Alexander Graf
2023-12-22 19:51 ` [PATCH v2 13/17] tracing: Recover trace buffers from kexec handover Alexander Graf
2023-12-22 19:51 ` [PATCH v2 14/17] tracing: Add kho serialization of trace events Alexander Graf
2023-12-22 19:51 ` [PATCH v2 15/17] tracing: Recover trace events from kexec handover Alexander Graf
2023-12-22 19:51 ` [PATCH v2 16/17] tracing: Add config option for " Alexander Graf
2023-12-22 19:51 ` [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO Alexander Graf
2023-12-22 21:19 ` Rob Herring
2023-12-23 14:30 ` Krzysztof Kozlowski
2023-12-23 23:20 ` Alexander Graf
2023-12-24 8:58 ` Krzysztof Kozlowski
2024-01-02 14:53 ` Rob Herring
2024-01-02 15:20 ` Rob Herring [this message]
2024-01-17 13:56 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240102152023.GA2821956-robh@kernel.org \
--to=robh@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anthony.yznaga@oracle.com \
--cc=arnd@arndb.de \
--cc=ashish.kalra@amd.com \
--cc=benh@kernel.crashing.org \
--cc=devicetree@vger.kernel.org \
--cc=dwmw@amazon.co.uk \
--cc=ebiederm@xmission.com \
--cc=graf@amazon.com \
--cc=hpa@zytor.com \
--cc=jgowans@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=madvenka@linux.microsoft.com \
--cc=mark.rutland@arm.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=skinsburskii@linux.microsoft.com \
--cc=thomas.lendacky@amd.com \
--cc=usama.arif@bytedance.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).