From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6799C606A31A for ; Sat, 24 Oct 2026 11:37:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=oa8NBxW3; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=alMJRejs DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=JGL3qTPNqshUoFon3YlDWfF5+DJcyIa46YLyW1IYigk=; b=oa8NBxW3u0A+jCkDCs8P7XrNFD fAtDJ2iLEgHbQzBdtjnMi2M/oQni8m0u4VSA9SlTN8s8Z9jGMc0UGYQ8XJrU/hwl0RR7EjKP8TpIc sO/l+qNJQeq4SJuVTaiPEe9091DaiyhxfUYRynI5m3sUKfemf6mCb4rgXtXwWcfd4tE185OJKVM/a Ay3vcKurKHv4c5Q+/yMa1xvM5o6SJR9T/NJ1vc9R5x3k30IDYvAtgaxiM5u2KXNNo4+iatsxb+KFi EN5EsdLQuIGgsIz6R6/p7PL8hE9+FKnLTqPrxszV6ZFQTQMg5jS1BM2UgJ4dgUyjW4OF8Q88qfy9N CXpqvR8w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xKa2R-000000008F6-2DNj; Sat, 24 Oct 2026 11:35:51 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xKa2P-000000008En-4AEL for linux-arm-kernel@lists.infradead.org; Sat, 24 Oct 2026 11:35:50 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 59DFE400C8; Sat, 24 Oct 2026 11:35:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CA9F1F01825; Sat, 24 Oct 2026 11:35:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792841749; bh=JGL3qTPNqshUoFon3YlDWfF5+DJcyIa46YLyW1IYigk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=alMJRejsFi9d108NFZiCBV/ZjD+QtbOYf6AFtksgqO7m4ZPfNoc2lLWXgUJsK02Mm dVtsxVCOCg9LtAPWHhyhbYJugKNIOC41oCcP+ndiJdDqk1NC2QBhk6CiK90gz6RV75 0Rf7aQxI3zlAQk4JnwbIM+XIoISdMm93OwiGyqAXdC2/w+RMGpBS8cKvu6PZs3GvSu 7ZwyvgAyhuE8xL0f/3ztTEjWPw3ASoeqZCEW5RUUMSTLSIx3PARIHuw/TNIbpK2ayV tAEtyXvvRb3gl7OhtKWFHC6La5U2M3MDcd3TrdgPW0vWp8otNapSqI0E8jVQ7dn6Hc pqHuk+XqN55WA== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xKa2M-00000006k7u-3Fum; Sat, 24 Oct 2026 11:35:46 +0000 Date: Sat, 24 Oct 2026 12:39:03 +0100 Message-ID: <87v76r8h0o.wl-maz@kernel.org> From: Marc Zyngier To: Qianhui Xu Cc: Thomas Gleixner , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] irqchip/gic-v3-its: Claim LPI tables inherited across kexec on DT In-Reply-To: <20261024075856.835932-1-xiaqinghuan@mail.ustc.edu.cn> References: <20261024075856.835932-1-xiaqinghuan@mail.ustc.edu.cn> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Archived-By: 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: xiaqinghuan@mail.ustc.edu.cn, tglx@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On Sat, 24 Oct 2026 08:58:56 +0100, Qianhui Xu wrote: > > From: Xu Qianhui > > When a kernel is kexec'd into while LPIs are enabled, the incoming kernel > finds GICR_CTLR.EnableLPIs set and tries to re-initialise the LPI tables > from scratch. That requires disabling LPIs first, which is not always > possible: on some implementations (e.g. Qualcomm SM8750) the EnableLPIs > bit is RES1 once set, the write to clear it is ignored, and > redist_disable_lpis() returns -EBUSY. its_cpu_init() then bails out > early, LPIs are never reprogrammed, and every MSI command queued against > the ITS waits for its completion timeout: measured 99 timeouts of about > 1.25 s each, pushing /init out from 1.3 s to 126 s. But you're missing the point. *nothing* works at all, and this has nothing to do with the command queue. Everything is dead. > > The tables themselves are still intact and usable, and the driver already > has a path for that (RDIST_FLAGS_RD_TABLES_PREALLOCATED), but it is gated > on the tables being reserved memory. On an EFI boot the outgoing kernel > records a persistent reservation; on a DT boot nothing does. Adding a What makes you think that EFI and DT are incompatible? 90% of my machines are DT based and yet boot with EFI. > memreserve entry is not an option either: the flattened DTB handed over by > the bootloader has no space left for a new one (-FDT_ERR_NOSPACE), and > kexec clones that blob when the image is loaded, long before the jump. > > So claim the inherited tables in the incoming kernel instead: reserve the > property table while LPIs are being probed (memblock still owns the pages, > well before memblock_free_all()), and the per-CPU pending tables when the > preallocated path is taken. The preallocated path is then selected > normally and the ITS keeps working across the handoff. No. This is way too late, and nothing guarantees that these are not already used for other purposes by the new kernel. I'm not interested in something that only has a statistical chance of working. Either it works always, or it doesn't at all. The only sane ways to do this is to either use EFI, or to configure the LPI tables from the bootloader, reserving them at boot time by sticking the reservation in the DT. They are then preserved along the whole of the kexec chain. That's what sane platforms do, and this is a long enough established practice. Thanks, M. -- Jazz isn't dead. It just smells funny.