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 4B7344A5EC3 for ; Thu, 24 Sep 2026 16:57:02 +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=1790269024; cv=none; b=XsXbaMJBPzcE54vHTujh9/HECQyes3exKsQkWnpo+f30qPlL184aRINOu44bgiJ2JfJ+l8JiTafCT0Fsf87T3Q9WjtU/yVD6P3UnTCdVy4k4payFBnqqLzyfe+q3udOb9z2IiZLS/5Hdo9xv7RqFEwcD87qVJ0YJ2msA37gzSKA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790269024; c=relaxed/simple; bh=gK5nHOMyGJrSKS1lhvfTZmlBAfaksbqVK72bCY88ToA=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=b+0/SZK7DKqqqBa2pf3DYvGxdaqINMHBZ+ElYVsTiNw7xWKB6TEG6EEOaWZPiNKttldpkCfXW8hZeAivd64c1u1x1yyKUdC1aJsNis/i1Pmxx8MJ8DO4yU56h8rGNgPJOB4RRMD2KICJf7ts65EieyHsdBgxGrtBNQUCEeglOKY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lb2IwhZK; 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="lb2IwhZK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBFA21F000FF; Thu, 24 Sep 2026 16:57:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790269022; bh=7xBAl8OyFpCzpWQlqcHmDCI/txbcQ4J/hmH1kiKvEaY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=lb2IwhZKl3Yeg+SXhYB2iUj99HHmqs/Sfds1W0AbzDT09ywvXSAV4QoWusjg1vSzD EoCqjWCP4AzLEhudLDn+Ra7lGRvIdmxlxA6OQC4NP7nkBmqJMsvLV+q2WSSUhDSJF0 q1oLCEtXVO4J69vP3LebrAr9R5F9I5GGk/PEKEJLntE51J8LiW0dRv3A/gi1Yn5AOs Rgxv4G3BWQSSYuJMFMyi0tk63orh1tvb5jXcN2nFeyh26dWgYLiXbs/LfLxQPZnOV8 EXBVbfnSuZI/zxEJcYuzw9yI5mBYgEvYOzJfL3a49EHHCEQnVGfg4Y4KswlG7EYRTG fUanCWbEo9Whw== 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 1x9mkm-0000000D7CV-2OdV; Thu, 24 Sep 2026 16:57:00 +0000 Date: Thu, 24 Sep 2026 17:57:00 +0100 Message-ID: <86qzii4mg3.wl-maz@kernel.org> From: Marc Zyngier To: Andrea della Porta Cc: Will Deacon , 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> <86se2z4yje.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/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 Thu, 24 Sep 2026 10:03:56 +0100, Andrea della Porta wrote: > > Hi Will and Marc, > > On 19:23 Wed 23 Sep , Marc Zyngier wrote: > > 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? > > It is not, in fact I should have put the EOI in all cases, but I just > focused on the crash driver by IPI only. The patch should be extended > but from the following discussion it does not seem relevant anymore. The other problem here is that you're looking at the IPI that got you there. But this IPI could have a higher priority than other interrupts (NMI), and therefore have preempted them whilst they were active. What happens with them? You'd need to iterate over all the interrupts that are in progress and EOI/DIR them *in the correct order*. Which would be replicating the GIC state machine. You can't do that in an arbitrary order as that would violate the interrupt life cycle which on some implementations results in a terminal SError. [...] > > > > > > 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. > > We're in a non returning handler which is about to shutdown the CPU in a few > instructions, so I'm not sure how to callback into the GIC driver. I reckon crash_kexec_post_notifiers and co could be of help, and could be to some extent tucked away in the HV-specific code (but see below for my full take on this). > > 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. > > That's what I suppose, but obviously I have no access to the implementation > so I canot add more. This is currently under investigation by the folks who > can, though... OK. It'd be interesting to understand why the existing code fails in your context, and getting feedback from the HV people would help. > > So the bottom line is that we need to wait for a patch from the hypervisor > vendor (and from any vendor that *could* suffer from the same issue), I guess? My take is that there is no point adding anything to the kernel until we understand exactly what is at stake. The kernel's expectation is that there is no difference between bare metal and virtualised, and that fundamental parts of the architecture (such as interrupts) should work as expected, no ifs, no buts. If this isn't fixable, or that we don't know when this will be fixed, we can always add an erratum workaround. But it needs to be captured as such, which implies that we have the full understanding of the issue. Thanks, M. -- Without deviation from the norm, progress is not possible.