Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2990457pxb; Fri, 12 Feb 2021 06:40:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJz3Z+9b/5/rtkRBEonaIiJ0DjOwgeee7JlHq6bUdm3EqTGFWSYuGOVSGGwmF8eLTnzDJJAu X-Received: by 2002:a17:906:eb88:: with SMTP id mh8mr3310514ejb.150.1613140848081; Fri, 12 Feb 2021 06:40:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613140848; cv=none; d=google.com; s=arc-20160816; b=KDmsM0CB51yXykSpTs0xXyBd/RpSg3eh3ZI75sI2G+opTmlIeDde1BEVM4OCm4E2MY ES+KxBVr7nG5K25E8t2/pdFEX75fYCg8ldrOqlyeNHDePRI/o/6QS+sbz+utP4MRSoX6 k86CwuJXvnJyQTkRyI9+5ysyfVobcymNpjMbYNaG0zIekE9e2DlM9DB9NbqtRNH7f33o godmwOArcZJga6thQD4FBrHYodZUQcrxZZnceR6KP2Xc8X2Bxousab+Ix8L5HoloyADT tOnfN2nmMbSonqJRKlhEUf0TIdWb+NGy6DJoTypdfLiNG0john7RY5mhtZ4gpJ4w0nOo YJjg== 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=n/CKkbLsPCXRwDm2kqzvRBrqkZqDSwy6R0mCXrIR9zs=; b=KFYOUT8tIekOU68PBXpJBBBJ3veGzS/22kOUHbUS0y3Rz/VPrGAOea4GqfPo/GrZvb IFz/feEOvKRW9mo3NXXtIaxFe8N87G+TlWVBFvF6ALpQJJPmIzGspnVHDlsNNEX3F4Dd 6LXm0zQArXmZa4a8y59Q5nzHQyDLenxaTqtRZ+yJ/iHrbZcQ4TFwouaP0pyRv+odA/eG j9w5OWF4Tkj+/SoCGTLQ+cRddF3flDartRuuAn9uZmlM3aJgb17RArDtUf03sloPryYH XY4mUk8z1+sJFvT4kVI6FPuNHWe6m8hzHEciQmHFqYcLZvrKKx+S5fJh23CD65cyzeOP L1QA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=FWRqGcPH; 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 l24si6287278eje.495.2021.02.12.06.40.23; Fri, 12 Feb 2021 06:40:48 -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=FWRqGcPH; 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 S230090AbhBLOjm (ORCPT + 99 others); Fri, 12 Feb 2021 09:39:42 -0500 Received: from mail.kernel.org ([198.145.29.99]:47436 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229647AbhBLOjk (ORCPT ); Fri, 12 Feb 2021 09:39:40 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 20B8B64E89; Fri, 12 Feb 2021 14:38:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613140739; bh=VM/hMIuNki+8AuFH8dta46Xcca/j9vD4S9PCcOVeQsI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FWRqGcPHxzqZvsn0B4Bf/KbzaCWzLCbuk0//h4yHfpml1nv4neMtG5cghJOLTOxMH EBfoSPv5L+/rsE3COCTObBf2LEMukyLAmuOc+TArWlww0/eJH1QCul1UCx46GHYC9A ygO0hJu9ZKn6RWKOGPy4aNWgzWRoxn69KdYstDfKoa6xs5ahXlgzqxPdf+jZ68nguQ 5oYPxsmOyxg/1s9ihHwhWnHvryOYlvQJ0CK7BvtE8cP7wOfO6Zyr0bnaw1DUs6Wxie Gs5J6TLJQiygY5snl6c2GG/ETwGAVuDglFuMoZ1hIr6PooCRR0uF9usfdP5seblfmM wi90akPnC1zFQ== Received: by mail-ej1-f45.google.com with SMTP id hs11so16053364ejc.1; Fri, 12 Feb 2021 06:38:59 -0800 (PST) X-Gm-Message-State: AOAM530Jt4vu+dcfjxyY08NZNJywZeNM77LBFSbRvWeuceGLj/tnciDq EJFUiMPaaVl9cJFCKHGvY0lZKyVx1UMxVaLHOQ== X-Received: by 2002:a17:906:1d44:: with SMTP id o4mr1930426ejh.130.1613140737428; Fri, 12 Feb 2021 06:38:57 -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> In-Reply-To: <8a3aa3d2-2eba-549a-9970-a2b0fe3586c9@linux.microsoft.com> From: Rob Herring Date: Fri, 12 Feb 2021 08:38:44 -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 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. The above change is also going to conflict, so I think this may have to wait. Or I'll take the common and arm bits and powerpc can be converted next cycle (or after the merge window). Rob