From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4373C83000 for ; Wed, 29 Apr 2020 17:01:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 87EA620B1F for ; Wed, 29 Apr 2020 17:01:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727791AbgD2RBa (ORCPT ); Wed, 29 Apr 2020 13:01:30 -0400 Received: from foss.arm.com ([217.140.110.172]:42480 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726456AbgD2RBa (ORCPT ); Wed, 29 Apr 2020 13:01:30 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C00F3106F; Wed, 29 Apr 2020 10:01:29 -0700 (PDT) Received: from [192.168.0.14] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3A5A63F73D; Wed, 29 Apr 2020 10:01:27 -0700 (PDT) Subject: Re: [PATCH v9 08/18] arm64: kexec: move relocation function setup To: Pavel Tatashin References: <20200326032420.27220-1-pasha.tatashin@soleen.com> <20200326032420.27220-9-pasha.tatashin@soleen.com> From: James Morse Cc: jmorris@namei.org, sashal@kernel.org, ebiederm@xmission.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, corbet@lwn.net, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, maz@kernel.org, vladimir.murzin@arm.com, matthias.bgg@gmail.com, bhsharma@redhat.com, linux-mm@kvack.org, mark.rutland@arm.com, steve.capper@arm.com, rfontana@redhat.com, tglx@linutronix.de, selindag@gmail.com Message-ID: Date: Wed, 29 Apr 2020 18:01:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200326032420.27220-9-pasha.tatashin@soleen.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pavel, On 26/03/2020 03:24, Pavel Tatashin wrote: > Currently, kernel relocation function is configured in machine_kexec() > at the time of kexec reboot by using control_code_page. > > This operation, however, is more logical to be done during kexec_load, > and thus remove from reboot time. Move, setup of this function to > newly added machine_kexec_post_load(). This would avoid the need to special-case the cache maintenance, so its a good cleanup... > Because once MMU is enabled, kexec control page will contain more than > relocation kernel, but also vector table, add pointer to the actual > function within this page arch.kern_reloc. Currently, it equals to the > beginning of page, we will add offsets later, when vector table is > added. If the vector table always comes second, wouldn't this be extra work to hold the value 0? You can control the layout of this relocation code, as it has to be written in assembly. I don't get why this would be necessary. > diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c > index ae1bad0156cd..ec71a153cc2d 100644 > --- a/arch/arm64/kernel/machine_kexec.c > +++ b/arch/arm64/kernel/machine_kexec.c > @@ -58,6 +59,17 @@ void machine_kexec_cleanup(struct kimage *kimage) > /* Empty routine needed to avoid build errors. */ > } > > +int machine_kexec_post_load(struct kimage *kimage) > +{ > + void *reloc_code = page_to_virt(kimage->control_code_page); > + > + memcpy(reloc_code, arm64_relocate_new_kernel, > + arm64_relocate_new_kernel_size); > + kimage->arch.kern_reloc = __pa(reloc_code); Could we move the two cache maintenance calls for this area in here too. Keeping it next to the modification makes it clearer why it is required. In this case we can use flush_icache_range() instead of its __variant because this now happens much earlier. > + return 0; > +} Regardless, Reviewed-by: James Morse Thanks, James