From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43F563A75B8 for ; Wed, 23 Sep 2026 18:23:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790187817; cv=none; b=iiw0DwwAYvUlCjuTw2EtiS+IAwSHq/ooH7S0SxunmbiWkj6vHLwt7hLiCogrBoq0UJuMFJQQTJPQkhmYiPT2RE9jtE+bQQwpDbC2EK8Pg4kYrN2WpBkiybU9huhl3v1ozuKX4b1sBQqo1rtgtIYxWnoua/Q/eHcMXd1+65hJ2nU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790187817; c=relaxed/simple; bh=zeSF0SL3RBCaNxr4VhT5nnS/1WIr/nA4Ru2ALYh1kuc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=bQ0RoeA8k7I/ToAfct+ZhbqYelhzquGLYDijSI21lmGr4g+Dgru7ODuMvZ762AxBcBqvZuFB50vpNbSfzU4T3Jv3f7yRt1snyM8QXUnjj5pPAyspu2oycz7OjY0dt6D38XAwNFKcVJvvt98hebCPX6UNZQtnMFP/849LqX8DOPk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ujyn3iJT; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ujyn3iJT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB2D71F000FF; Wed, 23 Sep 2026 18:23:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790187815; bh=t6B4THNzus+GzXrIfhXPAk47vkfxHDqxC1WCfQqccHc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Ujyn3iJTkV3JmC0qLaXbGZ5ZTEhuuKvy+ewy9RN8bzLH6nukKdH2f6TyFHhfkUbmT 3XEi+Or44r+YvYEM/NQWutvity32m+q1D0LrTJTcjwY+Owjhhviu7qibw0ssNmeMIR 8qoYcaaUpQOwlRthumppHs6DL/qkjHfUbeYRi0osXX+2YBP1a9QsvDgEkRoIZ3hUIQ +hyIixAhY9c9X/TpGIWFht73cT2A3FhzkSM3A+vhKkn12gqH0pD0y9i60DRmrpUq+E 3qRHUiL+8ZxDMBGdaTwX51Bh95X7TB7Io8lRa1i72aFRS5jMKiZwHl056ajc/gKQQI Ysxw7bk8q851Q== 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 1x9Rcz-0000000Cg9R-2RnN; Wed, 23 Sep 2026 18:23:33 +0000 Date: Wed, 23 Sep 2026 19:23:33 +0100 Message-ID: <86se2z4yje.wl-maz@kernel.org> From: Marc Zyngier To: Andrea della Porta , Will Deacon Cc: Catalin Marinas , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: smp: Signal EOI after handling IPI_CPU_STOP* In-Reply-To: References: <20260922140109.12780-1-andrea.porta@suse.com> 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) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: andrea.porta@suse.com, will@kernel.org, catalin.marinas@arm.com, mark.rutland@arm.com, 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 On Wed, 23 Sep 2026 16:41:42 +0100, Will Deacon wrote: > > [+Marc] > > On Tue, Sep 22, 2026 at 04:01:09PM +0200, Andrea della Porta wrote: > > On kdump/kexec, the boot CPU triggers an IPI_CPU_STOP (and subsequently > > an IPI_CPU_STOP_NMI if the first one does not respond) to the secondary > > CPUs, and the IPI handler eventually calls the firmware to shut down > > each CPU. Since the IPI is never acknowledged via EOI, the interrupt > > remains in an active state when the CPU goes idle. > > > > In a virtualized environment, if the hypervisor does not reset the > > interrupt state, this causes the crashkernel (with cmdline option > > maxcpus > 1) to be unable to synchronize between the boot CPU and > > secondary CPUs via IPI_CALL_FUNC, leading the kernel to wait indefinitely > > for the CPUs to respond. This has been observed with the Hyper-V > > implementation. > > Hmm, how is this different from panic()ing inside an interrupt > handler? Also, what is the architectural requirement for the hypervisor to do *anything* on the state of the interrupts? This doesn't happen on HW, and there is no reason to impose this on a hypervisor either. The expectations are that the guest kernel should reset the interrupt state on boot, and it feels that this is missing somehow, see below. > > > Both the Linux kernel and the Hyper-V firmware appear to violate the > > PSCI specification: > > > > - The PSCI spec states that the OS kernel must migrate any interrupt away > > from the CPU that is about to be shut down via CPU_OFF, which by extension > > implies that no active interrupts are allowed. The kernel does not > > currently do this in the kdump crash path. No. This is strictly about affinity, nothing else. It is there so that global devices can continue to have their interrupts handled. This evidently can't affect CPU-local interrupts. > > > > - The PSCI spec also states that the PSCI firmware must reset the CPU > > registers to their default values when turning on a CPU via the CPU_ON > > command. CPU registers. Not external peripherals such as the GIC. > > > > Fixing this on the kernel side has the advantage of being > > hypervisor-agnostic. > > > > Signal EOI at the end of the crash handler to prevent the subsequent > > crashkernel from hanging. > > > > Signed-off-by: Andrea della Porta > > --- > > arch/arm64/kernel/smp.c | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c > > index a61dc3016a117..cc7f3261fe537 100644 > > --- a/arch/arm64/kernel/smp.c > > +++ b/arch/arm64/kernel/smp.c > > @@ -988,6 +988,27 @@ void kgdb_roundup_cpus(void) > > } > > #endif > > > > +static void ipi_eoi(int ipinr) > > +{ > > + unsigned int cpu = smp_processor_id(); > > + struct irq_desc *desc; > > + struct irq_chip *chip; > > + struct irq_data *d; > > + > > + if (ipinr >= MAX_IPI) > > + return; > > + > > + desc = get_ipi_desc(cpu, ipinr); > > + > > + if (desc) { > > + chip = irq_desc_get_chip(desc); > > + d = irq_desc_get_irq_data(desc); > > + > > + if (chip && chip->irq_eoi) > > + chip->irq_eoi(d); > > + } > > +} > > Doesn't this hard-code the flow handler for the irqchip? It feels like it > would be better for the GIC driver to get a callback during the kexec > sequence (if it doesn't already) to prepare itself. Yeah, that's not an acceptable approach. The other observation is that the GIC drivers already clear the active state at boot time (gic_cpu_init()). So what isn't that working? Could it be that the hypervisor doesn't correctly handle the writes to GICR_ICACTIVER0 to nuke the active state? Because this works correctly on KVM as is. Thanks, M. -- Without deviation from the norm, progress is not possible.