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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 473AFC433EF for ; Thu, 28 Oct 2021 14:39:25 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id A35EC60FC4 for ; Thu, 28 Oct 2021 14:39:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A35EC60FC4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 25B2383216; Thu, 28 Oct 2021 16:39:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 6A791832AF; Thu, 28 Oct 2021 16:39:20 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 7AE9780607 for ; Thu, 28 Oct 2021 16:39:16 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=maz@kernel.org Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id ED3EF60FC4; Thu, 28 Oct 2021 14:39:14 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) 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 1mg6Yi-002EcA-PR; Thu, 28 Oct 2021 15:39:12 +0100 Date: Thu, 28 Oct 2021 15:39:12 +0100 Message-ID: <87v91h9ptb.wl-maz@kernel.org> From: Marc Zyngier To: Bharat Gooty Cc: Michael Walle , U-Boot Mailing List , Vladimir Oltean , Hou Zhiqiang , Rayagonda Kokatanur , Simon Glass , Priyanka Jain , Tom Rini , Roman Bacik Subject: Re: [PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree In-Reply-To: References: <20211027165454.1501398-1-michael@walle.cc> <871r45bk0h.wl-maz@kernel.org> <87y26da38o.wl-maz@kernel.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/27.1 (x86_64-pc-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: bharat.gooty@broadcom.com, michael@walle.cc, u-boot@lists.denx.de, vladimir.oltean@nxp.com, Zhiqiang.Hou@nxp.com, rayagonda.kokatanur@broadcom.com, sjg@chromium.org, priyanka.jain@nxp.com, trini@konsulko.com, roman.bacik@broadcom.com 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.34 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.2 at phobos.denx.de X-Virus-Status: Clean On Thu, 28 Oct 2021 11:27:44 +0100, Bharat Gooty wrote: > > [1 ] > On Thu, Oct 28, 2021 at 3:19 PM Marc Zyngier wrote: > > > On Thu, 28 Oct 2021 10:20:53 +0100, > > Bharat Gooty wrote: > > > > > > For GIC V3, once the LPI tables are programmed, we can not update it, > > > unless we do a reset. > > > > Please tell me something I don't know... > > > > For GIC V3 , once the Locality specific peripheral interrupts (LPI) table > is programmed and enabled, unless the GIC is reset, we can not re-program > the LPI tables. For these reasons, reserve the memory and program the GIC > redistributor PROPBASER and LPI_PENDBASE registers. > If we do not program the LPI table in the bootloader, during the Linux > boot, Linux will allocate the LPI table memory. Assume you want to boot a > new kernel and do the kexec kernel. For the kexec kernel boot, Linux will > again allocate the LPI table memory. But writing to the GIC registers will > fail. As the LPI for the redistributors is already enabled by the previous > Linux kernel, unless we do GIC reset, we can not update the LPI > tables. This really was a rhetorical question. I am painfully aware of most of the GIC's "features", having dealt with it in Linux and at the architecture level for the past 10+ years. > > > > > For the kexec kernel, where the reboot does not happen, in this case, > > > during the new kernel boot, the new LPI tables address will not be > > updated. > > > > Since July 2018, the Linux kernel is perfectly able to deal with this > > without any extra support. It will communicate the reservation to the > > secondary kernel, and the secondary kernel will happily use this. > > > > Can you specify the kernel version and the GIC versions which were used? Any kernel containing this commit: commit 5e2c9f9a627772672accd80fa15359c0de6aa894 Author: Marc Zyngier Date: Fri Jul 27 16:23:18 2018 +0100 irqchip/gic-v3-its: Allow use of LPI tables in reserved memory If the LPI tables have been reserved with the EFI reservation mechanism, we assume that these tables are safe to use even when we find the redistributors to have LPIs enabled at boot time, meaning that kexec can now work with GICv3. You're welcome. Tested-by: Jeremy Linton Tested-by: Bhupesh Sharma Tested-by: Lei Zhang Signed-off-by: Marc Zyngier And the version of the IP doesn't matter at all. > > > > For these reasons, We allocate the LPI table memory in u-boot and > > > reserve that memory. > > > > What sort of antiquated kernel are you using? And even if you are > > running something that predates the kernel changes, reserving the > > memory in the DT serves the same purpose. Why the custom node > > declaring the allocation? > > > > Tried using LTS 5.4 and 5.9 Linux kernels. Problem is updating the GIC V3 > registers with the new LPI table memory after enabling the LPI for the > redistributors. Then you are doing something wrong. There are two cases that work: (1) You are using EFI: nothing to do. The kernel will reserve the memory, configure the RDs, and the secondary kernel will happily use the same memory, as the address is conveyed in an EFI-specific table, without attempting to reprogram the RDs (2) You are not using EFI, and you need to reserve the memory *using the appropriate DT reservation mechanism* as well as program the RDs. The kernel will detect the reservation, and will not attempt to reprogram the RDs. If you invent your own binding, use another reservation mechanism or otherwise, this will not work. u-boot shouldn't expose this syscon node, because it makes no sense at all, and no upstream software knows about it. This code must die. M. -- Without deviation from the norm, progress is not possible.