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=-9.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 8E6ECC433DB for ; Tue, 9 Feb 2021 23:24:02 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 31EAF64E3E for ; Tue, 9 Feb 2021 23:24:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 31EAF64E3E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fluxnic.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=nsspsbZUoS/hU6pJNEP7mUGcXNhPjcnsb8vYme8t1e0=; b=L5zGAHCChZIwch10yjNtMQozY qDGcb1TF8E0+dZUYKB25PGFuztfGrGl48RnMXQ/LexABk2QSb8ogutZmfpJkuaEmejFEl2++qzmVq nmzVwn7Xn+2L65+WdT2XUAZ8UywKfGEo1tMTo7BfJ5ZzmK5Ddfer+wIGF6sGH40FeNFOOPzfxOJe+ CVil14Gitsa4wkM7AaaQgwwnFwjEf0j/ll+nP8+lHavgSewjuOfdSnqAb1+dA58VlZj0QgE9WMznY pNTrp676sIIWxjYv2H6kNX7rcaYoF390c9244+TPDODBIBO9yoMv+YbssoTCQcLQV5QIOPIiWc3XA p5hB4WnvA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9cLM-0003XR-AE; Tue, 09 Feb 2021 23:22:52 +0000 Received: from pb-smtp2.pobox.com ([64.147.108.71]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l9cLG-0003VR-Kb for linux-arm-kernel@lists.infradead.org; Tue, 09 Feb 2021 23:22:50 +0000 Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id E6DC6B1BF7; Tue, 9 Feb 2021 18:22:44 -0500 (EST) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version :content-type; s=sasl; bh=movaOwz9w5las/GuTHJnlgTXQIk=; b=c+ypZa +Rwgbf+LpUDLJ+MnPQXN+b7wVVA6udlILXqCVeMY/2Oe6QnwNGO5+bSrvR6t+Az3 4sGQpTP7jGqTtc4RPNBU/qGyFALV7RnoCndf+cBLWhdiNDN6xCyki0Y7WmvgXRFh lBaXy6CNs6TARj4ES//yCZ3y+y7NQFdsZ2HeM= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id DD0C5B1BF6; Tue, 9 Feb 2021 18:22:44 -0500 (EST) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fluxnic.net; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type; s=2016-12.pbsmtp; bh=xP1ze0hvuhX6urnSLWPbo3MhutiHq/SYrfibyzqUOI8=; b=TWiBxddyRhAxJAMZVZbGI/JOvvPzYJsgezDPIoaktpB0JqwXvvce3sIa6dk/nI479BvGocVyH8Tw8Rws4iDFojgarUxzJmKF8y9sD/c8IxzlS9zFQ9mbjvCnmtoJAEWv6DMnVPBs7nMHpkLAViszopojcs7u0dmkCwHboTjp6sU= Received: from yoda.home (unknown [24.203.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 620E2B1BF5; Tue, 9 Feb 2021 18:22:44 -0500 (EST) (envelope-from nico@fluxnic.net) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id 7D8EA2DA0140; Tue, 9 Feb 2021 18:22:43 -0500 (EST) Date: Tue, 9 Feb 2021 18:22:43 -0500 (EST) From: Nicolas Pitre To: Ard Biesheuvel Subject: Re: [PATCH 0/3] ARM: v7: get rid of boot time mini stack In-Reply-To: Message-ID: <52q680r8-9soq-705p-66qq-8qs8nq337or@syhkavp.arg> References: <20210208224959.13683-1-ardb@kernel.org> <10r5qp6n-pqr4-285n-646o-73o236124024@syhkavp.arg> <5n44qnn4-96p9-3q88-oqn8-6q3192q0n582@syhkavp.arg> MIME-Version: 1.0 X-Pobox-Relay-ID: B67B5D5E-6B2D-11EB-8854-74DE23BA3BAF-78420484!pb-smtp2.pobox.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210209_182246_861517_888582DA X-CRM114-Status: GOOD ( 28.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marc Zyngier , Linus Walleij , Android Kernel Team , Russell King , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 10 Feb 2021, Ard Biesheuvel wrote: > On Tue, 9 Feb 2021 at 23:59, Nicolas Pitre wrote: > > > > On Tue, 9 Feb 2021, Ard Biesheuvel wrote: > > > > > On Tue, 9 Feb 2021 at 00:12, Nicolas Pitre wrote: > > > > > > > > On Mon, 8 Feb 2021, Ard Biesheuvel wrote: > > > > > > > > > The v7 boot code uses a small chunk of BSS to preserve some register > > > > > contents across a call to v7_invalidate_l1 that occurs with the MMU and > > > > > caches disabled. Memory accesses in such cases are tricky on v7+, given > > > > > that the architecture permits some unintuitive behaviors (it is > > > > > implementation defined whether accesses done with the MMU and caches off > > > > > may hit in the caches, and on SoCs that incorporate off-core system > > > > > caches, this behavior appears to be different even between cache > > > > > levels). Also, cache invalidation is not safe under virtualization if > > > > > the intent is to retain stores issued directly to DRAM, given that the > > > > > hypervisor may upgrade invalidate operations to clean+invalidate, > > > > > resulting in DRAM contents to be overwritte by the dirty cachelines that > > > > > we were trying to evict in the first place. > > > > > > > > > > So let's address this issue, by removing the need for this stack to > > > > > exist in the first place: v7_invalidate_l1 can be rewritten to use fewer > > > > > registers, which means fewer registers need to be preserved, and we have > > > > > enough spare registers available. > > > > > > > > That is excellent. > > > > > > > > I wonder why r1-r3 were preserved though. > > > > > > > > > > r1 and r2 are documented in head.S as > > > > > > * The processor init function will be called with: > > > * r1 - machine type > > > * r2 - boot data (atags/dt) pointer > > > > > > but preserving the value of r3 does not seem necessary. Perhaps this > > > is a leftover from old code? > > > > Still, further down in the same comment it is said: > > > > * On return, the CPU will be ready for the MMU to be turned on, > > * r0 will hold the CPU control register value, r1, r2, r4, and > > * r9 will be preserved. r5 will also be preserved if LPAE. > > > > But you're now clobbering r1 and r2. And when this returns, code > > execution goes to __enable_mmu whose comment also mentions the expected > > r1 and r2 content. That would need adjusting too. > > > > No, r1 and r2 are preserved - they are stashed in r6/r7 across the > call to v7_invalidate_l1. r0, r3 and r12 are clobbered as well, but > those do not contain anything that needs to be preserved. OK, you're right. I didn't look at the whole code. Acked-by: Nicolas Pitre Nicolas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel