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 906B8606A320 for ; Mon, 26 Oct 2026 13:53:24 +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=tuHquvfa; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=dFBNLqWy 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=kCaZLfOe866RkzJW+w4WPIoxNgQcez1QZFd2FZRsiXo=; b=tuHquvfa5iTgOrQKJzsuY7O7x2 R65pPwiEqrfqcL6ZofEFwbU/AiyzBBHV4njmJKtMygbd44Z1YxgUZzud9Pub03hsFJYypeBJVTakc TKTU2So+F4LE474neBbyZew7dbLaxSs9TbH8866HEBPNj0BXGKO9S8K8I0KMI7blI9VwPDfANA58w Ntb3+Rpj4SezAbmSSzYvJGOsmCD1x0LvJIOE66/a8ZMqj7rDY/MTrCHq5VzSJC/a+bCF9EMY18fdD aoQUDKGji4q6yjDGr77fob6olRdm6mauz1A0y3SRtB2Yzp+RVsVJKb5iLWDtG0IyT6U1FW4kg+xHa +qHZGUjA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xLL8R-00000002eAo-1fSn; Mon, 26 Oct 2026 13:53:11 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xLL8P-00000002eAZ-47FC for linux-arm-kernel@lists.infradead.org; Mon, 26 Oct 2026 13:53:10 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 64643436AC; Mon, 26 Oct 2026 13:53:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 474A91F01825; Mon, 26 Oct 2026 13:53:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793022789; bh=kCaZLfOe866RkzJW+w4WPIoxNgQcez1QZFd2FZRsiXo=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=dFBNLqWymxgRyBgSIZZ5s34TdrOG/2EN6kjRdZcFDBcYrTPlgkj0mZ32V1ZcGSciQ GzRhZlFVUcKARG2bG0zVacm+y3OGuC6/JhWw4Ba6E7Bww1HDnwa/QpUN2S6XOSiUBI BioiP+/vSRMc0OGWUqYFH30D2gJbDfPUkL5labchLjIDnebMve5w3En7qxyz9AYmoy zAPwvjgW5kBdgLy/8LmHDQhIX1PRgvuVqaXVXYUQBGZyADfbRMxzrSZZTs4oaxyL+K MDjNroE4ZpZ87ZU8zyTqAXtFazNG79O05KWksg90pbud0V2yx90KV9g2PPD8ALZbzX 9EFD+ZjKYmefQ== 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.98.2) (envelope-from ) id 1xLL8M-00000007Iii-3un8; Mon, 26 Oct 2026 13:53:07 +0000 Date: Mon, 26 Oct 2026 13:53:06 +0000 Message-ID: <86y0bky3el.wl-maz@kernel.org> From: Marc Zyngier To: Qianhui Xu Cc: Thomas Gleixner , linux-arm-msm@vger.kernel.org, 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: <179301488974.13269.12823732532276833194@mail.ustc.edu.cn> References: <87v76r8h0o.wl-maz@kernel.org> <179301488974.13269.12823732532276833194@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-msm@vger.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 Mon, 26 Oct 2026 11:41:29 +0000, Qianhui Xu wrote: > > Hi Marc, > > Understood on all three points, and the series is withdrawn -- I am not > going to resend it in any form. Thanks. > > Just so it is on record that I got the reasoning right this time: > > - Inheriting LPI tables is not something the incoming kernel can decide to > fix up after the fact. By the time it runs, it can no longer tell which > of those pages are still the LPI tables and which are ordinary memory it > has already handed out, so any "claim" is a race with a statistical > chance of being correct. That is why it is either configured before the > handoff, or not at all. Indeed. By the time it gets to the GIC driver, the memory used by the LPI tables could be allocated to other things (page tables, for example), and memory corruption is very likely. > - EFI and DT are not alternatives: the reservation has to exist in > whichever description the next kernel is given, EFI memory map or DT > reserved-memory, and EFI booting a DT machine is the normal case. Correct. The EFI reservation is done through Linux-specific EFI tables that are available irrespective of the platform description method. DT reserved memory is also usable, but obviously has to be set from the initial boot point. > - Therefore the LPI tables have to be programmed and reserved by the > firmware/bootloader at boot and stay reserved across the whole kexec > chain. > > In our case the "bootloader" for a kexec chain is the kexec loader itself, > so the work moves there: add the reservation to the FDT that is handed over > (e.g. grow the blob when there is no space for the memreserve) and have the > loader program the tables, instead of the kernel trying to reclaim them. > Anything that needs LPIs will simply use a full reboot until that exists. If you're using Linux as your first stage bootloader (like petitboot), then the DT you produce has to have the reservation. If you're using u-boot without EFI as the bootloader, you can perform the reservation there. M. -- Without deviation from the norm, progress is not possible.