Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3152634pxb; Fri, 12 Feb 2021 10:26:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJy3Wk/eIUXoBeIbA+FZUkhaToRYejM4jmrqwx8jwYAbWgGom8ZKOnuLvNuxeUFLzA0LQU6J X-Received: by 2002:aa7:c755:: with SMTP id c21mr4745919eds.47.1613154389123; Fri, 12 Feb 2021 10:26:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613154389; cv=none; d=google.com; s=arc-20160816; b=QU1nmFR9nc7uz+6pRCPZOWfRN83otMeg6wZHxhD2002KFRf/9QfuznMepPfLeC3pXE bL55896RyOsZ2mfouN1UDxeYXFaCKl1seKpbN4eMJ4AricQ87c54cKuMRqbHkHdYOkeV 4wpIuEcS9o/rj0gKO0XP5a0LaXL+yz/4LlwbRLFUDTkCw7Al+XxVRZx7IU72FQ6pn7m0 +m2/uHSvOzVR686kJ/cMHOxqY/ulIrmAVw8aGSTn0aL4Pxu0JwzkDFcsC2dajpwJZMn2 gqzRabkL54DI85HcK8Ha+qjsAh6FfYdb+t0TMrtz9xZ9ZiH0sUMJfkKzwJg5fCp9LM5R VElQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=CCXxivjegbjOhnU+QG3U99SBqr4jDAUtoFIB/XT89uo=; b=cJAFw+XAYkfLLfmBBUsjzTm+G/YyYEy9PmVUeLu0WDC93dUa/Ka7Dy0wQPv3sAUDx+ TJUrLJnzd2hDJoQhb0KJ+yKK8RF+iXJ79jpCTqwpWM8hzttn3JMCmjqlVcAuIUMb8wgE 9/jvLK8ylLS1056DHghqbk4gqvDVuhcRxkQw7mUDXs9xPFBafr2J2ckkh/iXF0+DXqu0 HlSQX+im5EjQjHPkGA4Z6vvxp4juPldI47lVghqjsA1fdw/FiWwaj4jePbxh3tPaKAGs vnSJ9w8TlOIvlFYvDLlxRQNVpHDI+WmHzu08PVgIp4TfSruc7n4ln91vOaIet+5Q/5/y wC4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NXKvqHb7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c15si7161791ede.341.2021.02.12.10.26.04; Fri, 12 Feb 2021 10:26:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=NXKvqHb7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230053AbhBLSZF (ORCPT + 99 others); Fri, 12 Feb 2021 13:25:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:53514 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229558AbhBLSZE (ORCPT ); Fri, 12 Feb 2021 13:25:04 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 97AE464E99; Fri, 12 Feb 2021 18:24:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613154261; bh=i59A6KsNy0tuBkPE86R7oS3fgQDlOUtW1mMckoQBugI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NXKvqHb7A+THftvgjtBzxKYyRmPhlWrhWAUE1s5olkMvcyXKGGTsUbOfZ/Kbq+/Sp IJG5euh/BxNwmvojFqLHCbfWwl/eufDrPGlA1sO3o+LM/6rHmoJi77jpQ09sP8oqMU C9N4a4tUCFv/uT1NVHbea95+IDU7HK3tWOVFICI6FDKfuSgnqHVRtePViDIhHnWQsR oJwo38HOo9JZILJUiayMoRBXl10oEW4BImwzUxAQDfHDhxeWAGhUuAew2Jccvfpm6r R5CPg6RWJYG7fQd2KJiupQkfysRO7DOsfVBVvW7jwV7fdJgZ6NtqfhaCy5a3CN48En HbQa2a3Z8isuQ== Received: by mail-ej1-f47.google.com with SMTP id y9so629398ejp.10; Fri, 12 Feb 2021 10:24:21 -0800 (PST) X-Gm-Message-State: AOAM533VFgDrRwAWYdRgPVEnnAmG7tODJUCAkDnfGAh8AWE5P3vt98pz 2sY2pTn1ZqNnCQVJVPHb8ikqvL8RbeUOCqKx7A== X-Received: by 2002:a17:906:af41:: with SMTP id ly1mr4076035ejb.525.1613154260106; Fri, 12 Feb 2021 10:24:20 -0800 (PST) MIME-Version: 1.0 References: <20210209182200.30606-1-nramas@linux.microsoft.com> <20210209182200.30606-3-nramas@linux.microsoft.com> <87k0reozwh.fsf@manicouagan.localdomain> <8a3aa3d2-2eba-549a-9970-a2b0fe3586c9@linux.microsoft.com> <55685b61-dac0-2f24-f74a-939acf74a4f2@linux.microsoft.com> In-Reply-To: <55685b61-dac0-2f24-f74a-939acf74a4f2@linux.microsoft.com> From: Rob Herring Date: Fri, 12 Feb 2021 12:24:07 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v17 02/10] of: Add a common kexec FDT setup function To: Lakshmi Ramasubramanian Cc: Thiago Jung Bauermann , Mimi Zohar , "AKASHI, Takahiro" , Greg Kroah-Hartman , Will Deacon , Joe Perches , Catalin Marinas , Michael Ellerman , James Morse , Sasha Levin , Benjamin Herrenschmidt , Paul Mackerras , Frank Rowand , vincenzo.frascino@arm.com, Mark Rutland , dmitry.kasatkin@gmail.com, James Morris , "Serge E. Hallyn" , Pavel Tatashin , Allison Randal , Masahiro Yamada , Matthias Brugger , Hsin-Yi Wang , tao.li@vivo.com, Christophe Leroy , Prakhar Srivastava , balajib@linux.microsoft.com, linux-integrity@vger.kernel.org, "linux-kernel@vger.kernel.org" , linux-arm-kernel , devicetree@vger.kernel.org, linuxppc-dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 12, 2021 at 11:19 AM Lakshmi Ramasubramanian wrote: > > On 2/12/21 6:38 AM, Rob Herring wrote: > > On Thu, Feb 11, 2021 at 7:17 PM Lakshmi Ramasubramanian > > wrote: > >> > >> On 2/11/21 5:09 PM, Thiago Jung Bauermann wrote: > >>> > >>> There's actually a complication that I just noticed and needs to be > >>> addressed. More below. > >>> > >> > >> <...> > >> > >>>> + > >>>> +/* > >>>> + * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree > >>>> + * > >>>> + * @image: kexec image being loaded. > >>>> + * @initrd_load_addr: Address where the next initrd will be loaded. > >>>> + * @initrd_len: Size of the next initrd, or 0 if there will be none. > >>>> + * @cmdline: Command line for the next kernel, or NULL if there will > >>>> + * be none. > >>>> + * > >>>> + * Return: fdt on success, or NULL errno on error. > >>>> + */ > >>>> +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image, > >>>> + unsigned long initrd_load_addr, > >>>> + unsigned long initrd_len, > >>>> + const char *cmdline) > >>>> +{ > >>>> + void *fdt; > >>>> + int ret, chosen_node; > >>>> + const void *prop; > >>>> + unsigned long fdt_size; > >>>> + > >>>> + fdt_size = fdt_totalsize(initial_boot_params) + > >>>> + (cmdline ? strlen(cmdline) : 0) + > >>>> + FDT_EXTRA_SPACE; > >>> > >>> Just adding 4 KB to initial_boot_params won't be enough for crash > >>> kernels on ppc64. The current powerpc code doubles the size of > >>> initial_boot_params (which is normally larger than 4 KB) and even that > >>> isn't enough. A patch was added to powerpc/next today which uses a more > >>> precise (but arch-specific) formula: > >>> > >>> https://lore.kernel.org/linuxppc-dev/161243826811.119001.14083048209224609814.stgit@hbathini/ > >>> > >>> So I believe we need a hook here where architectures can provide their > >>> own specific calculation for the size of the fdt. Perhaps a weakly > >>> defined function providing a default implementation which an > >>> arch-specific file can override (a la arch_kexec_kernel_image_load())? > >>> > >>> Then the powerpc specific hook would be the kexec_fdt_totalsize_ppc64() > >>> function from the patch I linked above. > >>> > >> > >> Do you think it'd better to add "fdt_size" parameter to > >> of_kexec_alloc_and_setup_fdt() so that the caller can provide the > >> desired FDT buffer size? > > > > Yes, I guess so. But please define the param as extra size, not total > > size. The kernel command line size addition can be in the common code. > > Will do. Just to clarify - > > The common code will do: > > fdt_totalsize(initial_boot_params) + strlen(cmdline) + extra_fdt_size > > The caller will pass "extra_fdt_size" > ARM64 => 4KB > PPC64 => fdt_totalsize(initial_boot_params) - which will be updated when > the patch Thiago had referred to is merged. Yes, I'd leave the 4KB in there by default and arm64 use 0. Rob