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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 ADAB6C433E0 for ; Sat, 23 Jan 2021 01:02:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4377123B2A for ; Sat, 23 Jan 2021 01:02:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4377123B2A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=soleen.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9C6726B0005; Fri, 22 Jan 2021 20:01:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 99DC36B0007; Fri, 22 Jan 2021 20:01:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B3F46B0008; Fri, 22 Jan 2021 20:01:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0112.hostedemail.com [216.40.44.112]) by kanga.kvack.org (Postfix) with ESMTP id 75C3F6B0005 for ; Fri, 22 Jan 2021 20:01:59 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 440E88249980 for ; Sat, 23 Jan 2021 01:01:59 +0000 (UTC) X-FDA: 77735237958.09.mint82_160b31a27570 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 26668180AD811 for ; Sat, 23 Jan 2021 01:01:59 +0000 (UTC) X-HE-Tag: mint82_160b31a27570 X-Filterd-Recvd-Size: 5655 Received: from mail-ej1-f54.google.com (mail-ej1-f54.google.com [209.85.218.54]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Sat, 23 Jan 2021 01:01:58 +0000 (UTC) Received: by mail-ej1-f54.google.com with SMTP id r12so10177681ejb.9 for ; Fri, 22 Jan 2021 17:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PHDV0F8C9xV1vp1h4qwpCoKFhZYLm088KEHP1thlvVw=; b=RioQLWr8ugo0DlsJFFgTZ1skKROqX3tElaG7qVKsO1ExATj1jaapKuyc8wa4MtUXmc 4GWcvQe0O9w3B4WSwmgsrwlcwrG9seP2gqB7lkI1Am+SfLSjrzODjd71vCyxb7CLwy9+ 4Iv4YXUPKTWpcPDNV/rNLYeNqSEBuZ48ChE6bV/oEkxfBjzthdflfC43U+yjNaiOlmbx ZX3lPPpccT2+4g6VJAGTnDxGdfN4Uoz7pQt0KKvBjysqjnkNUDAxqknD22gL9n5g/uaE CQluVWVHzL0r1iwlfTPUp6U35jakRKixlLujrqlxnOSb6x6TbjbWReoYvXxYvaP5I/Ir 9tcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PHDV0F8C9xV1vp1h4qwpCoKFhZYLm088KEHP1thlvVw=; b=j46gF+FxxBZEz+/tKMwEFow3yh4NKYTsEWUG4lkhC8ZLfEkLRLlrcoq1003SBl+Pmk EzfaAUMpxLz/o6NE2AZcJBsTBzN6Q+OxQ8UX+4IpqitrWg/76j4DNi/2GilDja9p/TlJ 0J/Kl/r0AUGSTEeutCpLYJmrOXtnT78yM3UKCfRZUJvoe9XsnzkIzlnnn+pvWcYyQrmV JCxGZupqctIJTMMlNrJ8t78eGvrq6vVwNXE9xDI0ZBP/ZlAtDxGp4FGQvq+bWFT2dlCv qCtbOi/TEiSuw1mSbY3DWf/8ErPDgLSq6V9Op3tiHjeVZdR0ZWv64IucST1Bgdy7RDCT yqhw== X-Gm-Message-State: AOAM532q+liUC67HRW+emP/vQKsB1NpzWD7qUb+Gpm2j95cXA9lWRozm Eq1zN+gmw3sowCJz3ZG3FkSrWXKl98ChwN371Jztxg== X-Google-Smtp-Source: ABdhPJyDwoCJc13K0qCHh6qwD51iPWaoNHnrbKE5Ph4azKcwJVRrPO628EHxEm5a3QaN3e8sAxa2eLt6Zs5v1ZMDiuo= X-Received: by 2002:a17:907:96a5:: with SMTP id hd37mr996462ejc.541.1611363717599; Fri, 22 Jan 2021 17:01:57 -0800 (PST) MIME-Version: 1.0 References: <20200326032420.27220-1-pasha.tatashin@soleen.com> <20200326032420.27220-9-pasha.tatashin@soleen.com> In-Reply-To: From: Pavel Tatashin Date: Fri, 22 Jan 2021 20:01:21 -0500 Message-ID: Subject: Re: [PATCH v9 08/18] arm64: kexec: move relocation function setup To: James Morse Cc: James Morris , Sasha Levin , "Eric W. Biederman" , kexec mailing list , LKML , Jonathan Corbet , Catalin Marinas , Will Deacon , Linux ARM , Marc Zyngier , Vladimir Murzin , Matthias Brugger , linux-mm , Mark Rutland , steve.capper@arm.com, rfontana@redhat.com, Thomas Gleixner , Selin Dag Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Apr 29, 2020 at 1:01 PM James Morse wrote: > > 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... Yes, the computation should be moved from kexec-reboot to kexec-load when possible. > > > > 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. Yes, I moved it. > > In this case we can use flush_icache_range() instead of its __variant because this now > happens much earlier. True. > > > > + return 0; > > +} > > Regardless, > Reviewed-by: James Morse Thank you for your review. Pasha > > > Thanks, > > James