Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4141261imm; Thu, 17 May 2018 23:23:40 -0700 (PDT) X-Google-Smtp-Source: AB8JxZq8pEj5GlGstfb9rURNPpxYRMJ+js6Kt+oR4T6OvnWWmixpkF05hdDR55a3hDUqcDQiiuO+ X-Received: by 2002:a62:11dc:: with SMTP id 89-v6mr8163233pfr.18.1526624620529; Thu, 17 May 2018 23:23:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526624620; cv=none; d=google.com; s=arc-20160816; b=afY+GM6WOlAgi0RMjbEOEC7lFWvbnDjgchHrUtUWOJfF0AkXFKXmFfXl/Ljxktpwuc 948PEiyp1pGeY9/0Mo0d+t8FWzT3jL1cGej89OH2wHH9XC6mKwzizwqmq/ah4UK3MFix 3uU9Z0WtSaMpjW1zlnSScgobsDkc8yb9dLyTvCvEuKEfwrKvV0ND96Aay471KYvvZuo/ SRLvSWjG07JSxceNiWC/uFpmau9/k2XSXahtTFcl20+bnNpv6ZKwrZw6dLUFhyEqHYdG V5nvl0k+jzVlfy/9uaVoUBwHxY4WSHkh8lDVPiOmlRpGgco34IcSRbAK9ruGoT3OjQNm LoNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=Fmf2T/m57JrDf3lXwQ7bE/PkUMzGk/1/2gy9G6jMfTQ=; b=Pv+MG1sTV10UTTKJCXR5/PdxWf9luux1yDvo57SXCoSs7wcVSb1mTo4dZd6sCI86ij fJ/wVqrysW//+JC17jr1QnsnVCcKID5Byb6oaFCj1fkKC4EZbp6cA2wmeWnQ3s+531TP rVvifwupaZoDBQRh8llU3Oq4oJqsRgGs0DAJs3CXMCo2U9pwQkNRe2p94ZvHjp7V6R+W Yoo5gFa3Gn9FSBCGbVPErd7o/b6fOaCBHC+DSDbe9HXOYTCplCetWdml/FLUgVPb3/s5 C6NL50NznTIqzO62I7LeNGZkFR2p1du8B4CNs9PFwGLNaECSDqyBD0EV3aZIJqW7sucI 1UMQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=D7mJAwBN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l69-v6si2454114pga.106.2018.05.17.23.23.26; Thu, 17 May 2018 23:23:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=D7mJAwBN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752075AbeERGWy (ORCPT + 99 others); Fri, 18 May 2018 02:22:54 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:42039 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751281AbeERGWw (ORCPT ); Fri, 18 May 2018 02:22:52 -0400 Received: by mail-pf0-f195.google.com with SMTP id p14-v6so3248792pfh.9 for ; Thu, 17 May 2018 23:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Fmf2T/m57JrDf3lXwQ7bE/PkUMzGk/1/2gy9G6jMfTQ=; b=D7mJAwBNM7X1X9NfFOwKU2zIxn0/ksMpWJ5wmgQ4QDAe/r6kQINDhi5knfpOaCPUoK VUE0cSHPIk/rQgk/Aao5uTOHJjJ95fsapS4s8ZTtlF0UKTlXLcWv0QzZxhev5VqCj6tB eyaNP3TRdgUM4YaZ8bfLolypv+7f+NUiUFoUA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=Fmf2T/m57JrDf3lXwQ7bE/PkUMzGk/1/2gy9G6jMfTQ=; b=pSbVMNk20Pv6WcmLIVTYC260iJr6wHu1EmnvVZzSESP64mUNOpQnxo4Ev/fXVqckFl SzNQiQGQGEzqs228N/ZWch1M3vaM3fxGd8XqQUidueQ4R1UceC6CLxvvTGNTmhigcbww e2JiS8ZWT0YhbiXsg+xImU5zwvynESAA3bh5MpE3FHF8drNVRSkIUV09AHpBEgGyW04J yQtpcQHhYGthxHRTlC8mDKOa6V2/ynpALQT0aiVMra/MPzrmQlqCotxFFkxsygs7bhRq CWHl8cgpfvoCg2ERcPzCwqlwKX1TGyDW3D61kGUu0Nfpv0A1/0xKUFCliRMkFNHKDUrW 2UWw== X-Gm-Message-State: ALKqPwd9eZ7spXlv+Qg2i+U1WBPX2jXkjvf8G+9ummEZrpND9h2qKgVQ al05cuw0ZGKX821aQLPPBT3+jg== X-Received: by 2002:a63:7e08:: with SMTP id z8-v6mr6420100pgc.383.1526624572010; Thu, 17 May 2018 23:22:52 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id n25-v6sm10310756pgd.5.2018.05.17.23.22.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 23:22:51 -0700 (PDT) Date: Fri, 18 May 2018 15:22:49 +0900 From: AKASHI Takahiro To: James Morse Cc: catalin.marinas@arm.com, will.deacon@arm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, bhsharma@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 03/11] arm64: kexec_file: invoke the kernel without purgatory Message-ID: <20180518062248.GK2737@linaro.org> Mail-Followup-To: AKASHI Takahiro , James Morse , catalin.marinas@arm.com, will.deacon@arm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, bhsharma@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20180425062629.29404-1-takahiro.akashi@linaro.org> <20180425062629.29404-4-takahiro.akashi@linaro.org> <9c830fe8-56d8-b43a-6265-43d31dffe61a@arm.com> <20180507052208.GD11326@linaro.org> <20180515044542.GC2737@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org James, On Tue, May 15, 2018 at 05:15:52PM +0100, James Morse wrote: > Hi Akashi, > > On 15/05/18 05:45, AKASHI Takahiro wrote: > > On Fri, May 11, 2018 at 06:03:49PM +0100, James Morse wrote: > >> On 07/05/18 06:22, AKASHI Takahiro wrote: > >>> On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote: > >>>> On 25/04/18 07:26, AKASHI Takahiro wrote: > >>>>> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c > >>>>> index f76ea92dff91..f7dbba00be10 100644 > >>>>> --- a/arch/arm64/kernel/machine_kexec.c > >>>>> +++ b/arch/arm64/kernel/machine_kexec.c > >>>>> @@ -205,10 +205,17 @@ void machine_kexec(struct kimage *kimage) > >> > >>>>> cpu_soft_restart(kimage != kexec_crash_image, > >>>>> - reboot_code_buffer_phys, kimage->head, kimage->start, 0); > >>>>> + reboot_code_buffer_phys, kimage->head, kimage->start, > >>>>> +#ifdef CONFIG_KEXEC_FILE > >>>>> + kimage->purgatory_info.purgatory_buf ? > >>>>> + 0 : kimage->arch.dtb_mem); > >>>>> +#else > >>>>> + 0); > >>>>> +#endif > >> > >> > >>>> purgatory_buf seems to only be set in kexec_purgatory_setup_kbuf(), called from > >>>> kexec_load_purgatory(), which we don't use. How does this get a value? > >>>> > >>>> Would it be better to always use kimage->arch.dtb_mem, and ensure that is 0 for > >>>> regular kexec (as we can't know where the dtb is)? (image_arg may then be a > >>>> better name). > >>> > >>> The problem is arch.dtb_mem is currently defined only if CONFIG_KEXEC_FILE. > >> > >> I thought it was ARCH_HAS_KIMAGE_ARCH, which we can define all the time if > >> that's what we want. > >> > >> > >>> So I would like to > >>> - merge this patch with patch#8 > >>> - change the condition > >>> #ifdef CONFIG_KEXEC_FILE > >>> kimage->file_mode ? kimage->arch.dtb_mem : 0); We don't need "kimage->file_mode ?" since arch.dtb_mem is 0 if !file_mode. > >>> #else > >>> 0); > >>> #endif > >> > >> If we can avoid even this #ifdef by always having kimage->arch, I'd prefer that. > >> If we do that 'dtb_mem' would need some thing that indicates its for kexec_file, > >> as kexec has a DTB too, we just don't know where it is... > > > > OK, but I want to have a minimum of kexec.arch always exist. > > I'm curious, why? Its 32bytes that is allocated a maximum of twice. I believe that I'm a stingy minimalist :) > (my questions on what needs to go in there were because it looked like a third > user was missing...) > > > > How about this? > > > > | struct kimage_arch { > > | phys_addr_t dtb_mem; > > | #ifdef CONFIG_KEXEC_FILE > > #ifdef in structs just breeds more #ifdefs, as the code that accesses those > members has to be behind the same set of conditions. > > Given this, I prefer the #ifdefs around cpu_soft_restart() as it doesn't force > us to add more #ifdefs later. OK > For either option without purgatory_info: > Reviewed-by: James Morse Thanks, -Takahiro AKASHI > > Thanks, > > James