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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5CF57E77188 for ; Wed, 8 Jan 2025 15:42:44 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 7C2BF800DF; Wed, 8 Jan 2025 16:42:42 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="dtV7wnFk"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 111AA80196; Wed, 8 Jan 2025 16:42:41 +0100 (CET) Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id D3CCD8006D for ; Wed, 8 Jan 2025 16:42:38 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=maz@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id DBDEBA4189C; Wed, 8 Jan 2025 15:40:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4600C4CEDD; Wed, 8 Jan 2025 15:42:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736350956; bh=sXau6sHrOZtBSOx2xsa4tIj3vSut2nvjsnLvyVosMr4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dtV7wnFk370u0IbYeqzd2qPWcvjvX37nWWjMqLHZhbf+f6KlmKH2n+dxLWkWkL8g/ +H5V60qnjY4+eRxBZiImAtLNlCmUKiX7gZnUbm/MlzNul6k+Wwhf/ZQGOwQkOQB2+A XecU8J6fgm337tTdrEUnPVxGgk2mCkP4xji/E7XrRsT93pQj/OPUcYv4QaYqsWyaeL iQnFHKZpXyyzRCjp9VkO4Gaf9xQkLnsm0PoLRAavZ5VtbvpNq2zSLFCP9v1/WQr7OX jb8Yqtnbe5HIG/PwzCy4cSViD32+9f0pNslgZndJvqmYrADcwmSUeqUvLeBMR98MGb MpefZa+nXlNmw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tVYCY-00ACyJ-E3; Wed, 08 Jan 2025 15:42:34 +0000 Date: Wed, 08 Jan 2025 15:42:33 +0000 Message-ID: <86r05dwbva.wl-maz@kernel.org> From: Marc Zyngier To: Caleb Connolly Cc: Andre Przywara , Neil Armstrong , Patrick Rudolph , Peter Hoyes , =?UTF-8?B?UGllcnJlLUNsw6ltZW50?= Tosi , Simon Glass , Sumit Garg , Tom Rini , u-boot-qcom@groups.io, Ilias Apalodimas , u-boot@lists.denx.de Subject: Re: [PATCH] armv8: mmu: don't switch to emergency tlb when adding a dynamic mapping In-Reply-To: <37c914cd-8f66-4474-8b88-7464b256cd49@linaro.org> References: <20250108142235.1194640-1-caleb.connolly@linaro.org> <86septwdlr.wl-maz@kernel.org> <37c914cd-8f66-4474-8b88-7464b256cd49@linaro.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: caleb.connolly@linaro.org, andre.przywara@arm.com, neil.armstrong@linaro.org, patrick.rudolph@9elements.com, Peter.Hoyes@arm.com, ptosi@google.com, sjg@chromium.org, sumit.garg@linaro.org, trini@konsulko.com, u-boot-qcom@groups.io, ilias.apalodimas@linaro.org, u-boot@lists.denx.de X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean On Wed, 08 Jan 2025 15:19:07 +0000, Caleb Connolly wrote: > > Hi Marc, > > Thanks for your comments. > > On 08/01/2025 16:05, Marc Zyngier wrote: > > On Wed, 08 Jan 2025 14:22:24 +0000, > > Caleb Connolly wrote: > >> > >> This seems to cause crashes on a bunch of Qualcomm platforms. It's safer > >> to just update the live table and flush it. > > > > You may want to provide a bit more information, because that's not > > much to go on, really. > > Best I have is "the board hangs and then resets when trying to switch > pagetables", I didn't manage to narrow it down exactly, but since it > seems to work to update the tables without switching that feels like a > better approach at least for now. I think you should completely characterise the issue before changing things like this. My hunch is that the so-called "emergency" page tables do not map the page tables you're modifying. Or something along those lines. But you really want to get to the bottom of it. > > In hindsight, this mmu_map_region() function is not great in a lot of > ways, I'm still getting my head around the MMU and I expect this will > keep being improved. > > > >> > >> Signed-off-by: Caleb Connolly > >> --- > >> arch/arm/cpu/armv8/cache_v8.c | 11 ++--------- > >> arch/arm/include/asm/system.h | 3 +-- > >> drivers/soc/qcom/cmd-db.c | 2 +- > >> 3 files changed, 4 insertions(+), 12 deletions(-) > >> > >> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c > >> index e6be6359c5d9..43051d156122 100644 > >> --- a/arch/arm/cpu/armv8/cache_v8.c > >> +++ b/arch/arm/cpu/armv8/cache_v8.c > >> @@ -338,9 +338,9 @@ static void map_range(u64 virt, u64 phys, u64 size, int level, > >> size -= next_size; > >> } > >> } > >> > >> -void mmu_map_region(phys_addr_t addr, u64 size, bool emergency) > >> +void mmu_map_region(phys_addr_t addr, u64 size) > >> { > >> u64 va_bits; > >> int level = 0; > >> u64 attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) | PTE_BLOCK_INNER_SHARE; > >> @@ -350,19 +350,12 @@ void mmu_map_region(phys_addr_t addr, u64 size, bool emergency) > >> get_tcr(NULL, &va_bits); > >> if (va_bits < 39) > >> level = 1; > >> > >> - if (emergency) > >> - map_range(addr, addr, size, level, > >> - (u64 *)gd->arch.tlb_emerg, attrs); > >> - > >> - /* Switch pagetables while we update the primary one */ > >> - __asm_switch_ttbr(gd->arch.tlb_emerg); > >> - > >> map_range(addr, addr, size, level, > >> (u64 *)gd->arch.tlb_addr, attrs); > >> > >> - __asm_switch_ttbr(gd->arch.tlb_addr); > >> + flush_dcache_range(gd->arch.tlb_addr, gd->arch.tlb_size); > > > > Why would you invalidate anything when *mapping* something? By > > definition, if there was nothing mapped before, there is nothing to > > invalidate (hint: the architecture forbids negative caching). > > This isn't flushing the region or TLB, it's flushing the translation > table we just modified. Ah, you're obviously right. I can't read today... But it then begs the question: are the page tables configured to be accessed by the page-table walker in a non-cacheable fashion? That'd be rather silly, and the only reason why you'd need any form of CMO at this point. > I'm wondering if this tlb_addr variable is misnamed, I'm reading ARM > docs which suggest the TLB is some cache inside(?) the MMU, but this > tlb_addr in U-Boot actually points to the translation table in memory if > my understanding is correct? That's my impression, but each time I look at this code, I feel a bit sick... M. -- Without deviation from the norm, progress is not possible.