Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp6606126rdb; Tue, 2 Jan 2024 07:20:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IFcb0X2ilLndZQKTrrn3Fei+0ehm7fW+5MAPhaboJpb1EdfyPrJBaUiNXYVa7GBmY6LxEzl X-Received: by 2002:a05:6512:3e2a:b0:50e:74c6:895f with SMTP id i42-20020a0565123e2a00b0050e74c6895fmr7042138lfv.115.1704208836399; Tue, 02 Jan 2024 07:20:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704208836; cv=none; d=google.com; s=arc-20160816; b=s72faOJvLlAP4dCsJjU3JF3DdoEsInFDR4vNxQAjuS3+nn1hBz9Qf3395Wukfcjc5R 7KHuc4tHjLu9VM4qbbowrkAu+3yqGI9Vh0uaTH88lQknu/bxlGI+JAm8pGEF1d53qxRY zY1Ombh5uhk8bTGhcDWRBXOcOrdHohHmjC7w9jltzU9q8QFTQwpu/ZdOqJE8kG4F9muB F8/7WtDPzIzRWL71fiG9xqZaE8/H2d/S+IjX3A4zHdn7mKrCm6Y0j6Sats+FYbwVw15o yrgzig5fw6+R5o87iqbddLgmswMeScXFaA3p0FOOkIMR/va6ARspPj8TYYw3bCTUlbZC em4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=5597WxKtMwpLooO25UkqXhsO2exDLV1j3RbPnCq0AOc=; fh=sOpjZrXvTsI10Nww6R6JzuSdr5tmwRGdAUNuIMrt6UQ=; b=ZBk/RmzqDH4dtu7X3GChBBZg2SlQ4/dge4jgGBECHvM8i2BHXeaGliDuGn8cUSSlO+ qCbkPfDS0GJko+rw3LyO4KdkTT5bLLq0xXgFDAXy/VQJwvuybihiSDIJyZF24IwpJJnq FMetkx+mI66zmgeLW/sxpL718R8QgrNAByDjy6s74UXdeFXnA9bICJUPmptZ9yV+ObsA lktlbmyV/c1hB2e2y7/3NY0R9KZxdKCq+YngMmwtYfqTK8g4uU2dhmefAvGeNvVvOe/l VgGYJFpew7L1J3F/zfosMmouMO8sFbND6s14cEec4+CdrkBwPHS4dFg2dmBUSIJCWwMN GTpQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SqEPk9zN; spf=pass (google.com: domain of linux-kernel+bounces-14553-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14553-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id z8-20020a056402274800b005541f5ef014si11382803edd.430.2024.01.02.07.20.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 07:20:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-14553-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=SqEPk9zN; spf=pass (google.com: domain of linux-kernel+bounces-14553-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-14553-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 2530D1F22F56 for ; Tue, 2 Jan 2024 15:20:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1CEA914A82; Tue, 2 Jan 2024 15:20:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SqEPk9zN" X-Original-To: linux-kernel@vger.kernel.org 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 3D68113AE9; Tue, 2 Jan 2024 15:20:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 335A1C433C8; Tue, 2 Jan 2024 15:20:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704208826; bh=28yPedgGByxBs/XllHPUgTPObBuags0avxhjHUIO2lA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SqEPk9zNaSyGDVA+YezzLsKj3ZNQGZ0SC4yCM9VyBETW2lskULwf3YW1bzCtNQIfP 6uXhHnR+VyjNxAdfsAuGy3PHqdk6b8MxmTW8LYv8wBb4ItzWZw49ksPEkR06n89PFp 2SHwc5dxr4TpgSfLoEJwYJVg/H6eXbQixr64Xmfg+I5UB0X4IH3NAAjmjbwdHFlysM UpyPsK4q/fnx9eBausPSz+cLglyeXqhW6ZWKNvjm1TKrQumi+l1lHl2hw3OUh/RrfO moE9dADO9rGte6dRtTv4Lf6g34Xmghec8dAzDY6uXDe6/E/fPOAc7PHu2mFtiS2u5m S8IIs3i6VEKvg== Received: (nullmailer pid 2861879 invoked by uid 1000); Tue, 02 Jan 2024 15:20:23 -0000 Date: Tue, 2 Jan 2024 08:20:23 -0700 From: Rob Herring To: Alexander Graf 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 , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Steven Rostedt , Andrew Morton , Mark Rutland , Tom Lendacky , Ashish Kalra , James Gowans , Stanislav Kinsburskii , arnd@arndb.de, pbonzini@redhat.com, madvenka@linux.microsoft.com, Anthony Yznaga , Usama Arif , David Woodhouse , Benjamin Herrenschmidt Subject: Re: [PATCH v2 17/17] devicetree: Add bindings for ftrace KHO Message-ID: <20240102152023.GA2821956-robh@kernel.org> References: <20231222193607.15474-1-graf@amazon.com> <20231222195144.24532-1-graf@amazon.com> <20231222195144.24532-12-graf@amazon.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: <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 > --- > .../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 > + > +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 > + > +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 > + > +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 > > >