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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 34976C4338F for ; Wed, 11 Aug 2021 15:16:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0E6F460FC0 for ; Wed, 11 Aug 2021 15:16:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233157AbhHKPRE (ORCPT ); Wed, 11 Aug 2021 11:17:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:51934 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233079AbhHKPPe (ORCPT ); Wed, 11 Aug 2021 11:15:34 -0400 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 E124760F21; Wed, 11 Aug 2021 15:14:47 +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 1mDpwM-004Mac-2z; Wed, 11 Aug 2021 16:14:46 +0100 Date: Wed, 11 Aug 2021 16:14:45 +0100 Message-ID: <87im0c9foa.wl-maz@kernel.org> From: Marc Zyngier To: Thomas Gleixner Cc: Valentin Schneider , linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, Will Deacon , Mark Rutland , Sebastian Andrzej Siewior , Mel Gorman , Ard Biesheuvel Subject: Re: [SPLAT 2/3] irqchip/gic-v3-its: Sleeping spinlocks down gic_reserve_range() In-Reply-To: <87a6lop3mi.ffs@tglx> References: <20210810134127.1394269-1-valentin.schneider@arm.com> <20210810134127.1394269-3-valentin.schneider@arm.com> <87y2989xhh.wl-maz@kernel.org> <87a6lop3mi.ffs@tglx> 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: tglx@linutronix.de, valentin.schneider@arm.com, linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, will@kernel.org, mark.rutland@arm.com, bigeasy@linutronix.de, mgorman@techsingularity.net, ardb@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 11 Aug 2021 13:28:21 +0100, Thomas Gleixner wrote: > > On Wed, Aug 11 2021 at 09:50, Marc Zyngier wrote: > > On Tue, 10 Aug 2021 14:41:26 +0100, > > Valentin Schneider wrote: > > The issue is that although the redistributor tables have been > > allocated ahead of time (outside of any cpuhp callback), they cannot > > be programmed into the RDs until the corresponding CPUs have been > > brought up (the registers may not be accessible). > > > > For the same reason, we don't know whether we can free them (because > > there is already a table programmed there) or have to reserve them > > with an efi_mem_reserve_persistent() call. efi_mem_reserve_iomem() > > uses GFP_ATOMIC for its allocation, but this is not sufficient for RT > > anymore. > > > > We could postpone the reservation of the memory to a later point (it > > is only useful for kexec), but it isn't clear where that point is. The > > CPU is not quite up yet, and we can't easily IPI the boot CPU to do > > the reserve call. > > Right, but don't you know about the need for reservation _before_ > bringing the CPU up? Unfortunately not. To find out, you need to access a pair of per-CPU registers which are not guaranteed to be powered-on until the corresponding CPU has made it into the kernel (the firmware will power things on as part of bringing the CPU up). Which is why we always allocate the memory upfront for all the CPUs, and each CPU either frees the memory if it already had something in its redistributor, or point the redistributor to the memory and reserves it. This is probably the most epic fail of the GICv3 architecture... Thanks, M. -- Without deviation from the norm, progress is not possible.