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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 40CD9C433F5 for ; Thu, 19 May 2022 15:27:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 985DC6B0071; Thu, 19 May 2022 11:27:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 935F26B0072; Thu, 19 May 2022 11:27:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FDB66B0073; Thu, 19 May 2022 11:27:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6FF8C6B0071 for ; Thu, 19 May 2022 11:27:36 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 3CB4C80CF5 for ; Thu, 19 May 2022 15:27:36 +0000 (UTC) X-FDA: 79482872112.21.785FCD4 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf03.hostedemail.com (Postfix) with ESMTP id B03572003A for ; Thu, 19 May 2022 15:27:24 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 8D52ECE2516; Thu, 19 May 2022 15:27:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5DC7C385AA; Thu, 19 May 2022 15:27:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652974048; bh=fWzT1RDzL+g/G2pbgJJD/u9obC3MZhKB4yK9conyL8g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KhPlyqr5DQ+2cxzW0xu4vYkoXbmxOHVwbib+1FOdSi4DyM1fdNRJKpkCXmhKC8/sw jNg5Ewr2ACxNFq6z9vUY4tGKAxaJ6wujFNx5o7sLHygM2LxCMvsb+AXZ+kJbtwHbrm TcVxENBVaAuttLzbvtbAahxCC7LXKKuezdvoJFBMa9CL6AZPR13x9yJAJs3w9JdE2M gILeHgLB+1/mYxOpjc9gAt4SIVhmBzql+/b7dKEEToGvpMwDfrRpEtcjpy6FnzQ5iP 1yGgwc3aZNTv1BV6VUHo14UYj1DGJ41lfxRRnI3gGhcTloxiboRbNY0M0VvQwEOy+f tiNlDxh+Nzn/g== Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nri3i-00CSzu-B2; Thu, 19 May 2022 16:27:26 +0100 MIME-Version: 1.0 Date: Thu, 19 May 2022 16:27:26 +0100 From: Marc Zyngier To: Vivek Kumar Cc: corbet@lwn.net, catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, axboe@kernel.dk, rafael@kernel.org, akpm@linux-foundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-block@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, len.brown@intel.com, pavel@ucw.cz, paulmck@kernel.org, bp@suse.de, keescook@chromium.org, songmuchun@bytedance.com, rdunlap@infradead.org, damien.lemoal@opensource.wdc.com, pasha.tatashin@soleen.com, tabba@google.com, ardb@kernel.org, tsoni@quicinc.com, quic_psodagud@quicinc.com, quic_svaddagi@quicinc.com, Prasanna Kumar Subject: Re: [RFC 1/6] arm64: hibernate: Introduce new entry point to kernel In-Reply-To: <1652860121-24092-2-git-send-email-quic_vivekuma@quicinc.com> References: <1652860121-24092-1-git-send-email-quic_vivekuma@quicinc.com> <1652860121-24092-2-git-send-email-quic_vivekuma@quicinc.com> User-Agent: Roundcube Webmail/1.4.13 Message-ID: <1d517a7598f7833196ec0c8258816aba@kernel.org> X-Sender: maz@kernel.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: quic_vivekuma@quicinc.com, corbet@lwn.net, catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, axboe@kernel.dk, rafael@kernel.org, akpm@linux-foundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-block@vger.kernel.org, linux-pm@vger.kernel.org, linux-mm@kvack.org, len.brown@intel.com, pavel@ucw.cz, paulmck@kernel.org, bp@suse.de, keescook@chromium.org, songmuchun@bytedance.com, rdunlap@infradead.org, damien.lemoal@opensource.wdc.com, pasha.tatashin@soleen.com, tabba@google.com, ardb@kernel.org, tsoni@quicinc.com, quic_psodagud@quicinc.com, quic_svaddagi@quicinc.com, quic_kprasan@quicinc.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-Rspamd-Queue-Id: B03572003A X-Stat-Signature: b5yg8x8ocompiqphac9enqpg6qmdb9sa Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=KhPlyqr5; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of maz@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=maz@kernel.org X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1652974044-550056 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 2022-05-18 08:48, Vivek Kumar wrote: > Introduce a new entry point to hibernated kernel image. > This is generally needed when bootloader restores the > hibernated image from disc to ddr and passes control > to it by turning off the mmu, also initialize this new > entry point with cpu_resume which turns on the mmu and > then proceeds with restore routines. > > Signed-off-by: Vivek Kumar > Signed-off-by: Prasanna Kumar > --- > arch/arm64/kernel/hibernate.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/arch/arm64/kernel/hibernate.c > b/arch/arm64/kernel/hibernate.c > index 6328308..4e294b3 100644 > --- a/arch/arm64/kernel/hibernate.c > +++ b/arch/arm64/kernel/hibernate.c > @@ -74,6 +74,14 @@ static struct arch_hibernate_hdr { > void (*reenter_kernel)(void); > > /* > + * Another entry point if jump to kernel happens with mmu disabled, > + * generally done when restoring hibernation image from bootloader > + * context > + */ > + > + phys_addr_t phys_reenter_kernel; > + > + /* > * We need to know where the __hyp_stub_vectors are after restore to > * re-configure el2. > */ > @@ -116,6 +124,7 @@ int arch_hibernation_header_save(void *addr, > unsigned int max_size) > arch_hdr_invariants(&hdr->invariants); > hdr->ttbr1_el1 = __pa_symbol(swapper_pg_dir); > hdr->reenter_kernel = _cpu_resume; > + hdr->phys_reenter_kernel = __pa(cpu_resume); > > /* We can't use __hyp_get_vectors() because kvm may still be loaded > */ > if (el2_reset_needed()) So here, you are creating a new ABI with the bootloader, based on a data structure that isn't mean't to be ABI. It means that we wouldn't be allowed to ever change this data structure, as this would mean having to update the bootloader in sync. Clearly, this isn't acceptable. M. -- Jazz is not dead. It just smells funny...