From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792844266; b=cbhPT2alpcgetaKOzGL7Vrzx5lgtCLePlGnNO5zNgPILlqv6Uv6Hi+EmabdpcyF3fDZy d8oVBguAxkTxQAUrQb2AyRtnQb6OdIcaZ1tBmWFMphxt3/Kep8MJN1RiuYnxMXiEgtSWK /uG516/BBoudimZpzhcLY1NdALYpuNcUQ8SS2Fd9dBKNk1hRCMI2tzuzyP4ygxG9/j0g7 TLQYwOQI5QVFM8Ql6Lj3AKf74MyGQUfv6jRrwerWzy4jvncPXHkwHpw4CEQ4QaiqW3IN2 NUitFCPANe9u6XPD5ieBAY8J89aOZ3WLHRqnxuh6utboq9iQJHhEC/seUJa03fKI5RA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792844266; h=Received:DKIM-Signature:Received:Date:Message-ID:From:To:Cc:Subject: In-Reply-To:References:User-Agent:MIME-Version:Content-Type: X-SA-Exim-Connect-IP:X-SA-Exim-Rcpt-To:X-SA-Exim-Mail-From: X-SA-Exim-Scanned; bh=R+Kivv+zlEGPU+9SEUXQD6rceDKEZP4lAk4GmwDpTwk=; b=M/SDOipRVANESD/wWmifyi/KfzwitLoRBJGDGI3+p457tdBNr08jJVy+fYDZMqrmfCfF c8Dzx1h0wjdRgiZHoOhTG79I57N/gg4I9W8OAPuWhUI1DQPIDwdZSRc1Smhq0kYDJhJCy YagPZLMyb9RJ3WN3yJ8BZs4ggIvaFXv4VG17UbAVrRCYuzxOsct2ph5t6JaQZuP21B9/z LZ+DdMeX4bsDtH3MP1wvhK44TXWCq8wunK/i7JwYloBPCB9AFDnN8Kj/wyQvUoEaD91qn 4vi4YPWzbgLxksS2iP3P1rRixVAd1ilMd/X26jNVBexJE3cC5eeXVPnrD1znvc6wXfA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=cuzqdhn0; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 56FE9606A31A; Sat, 24 Oct 2026 12:17:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=cuzqdhn0 Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE12D1F01825; Sat, 24 Oct 2026 12:17:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792844265; bh=R+Kivv+zlEGPU+9SEUXQD6rceDKEZP4lAk4GmwDpTwk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=cuzqdhn04FqsErQkVJnYS7+La9ms9fOlIoOQr1y5n1F7G0rsuKDu/jFUgPLRTtMGN fouh6gEYOFgOqVQIHuT95nfLObp9mfDkaxxhZCVmO1q7iyOcnwWsSMba2XgmUzIRLw YsDuYVNuwTMTe41snOBfkhsD7io6gSIW/DU5yyNQFUy6enSUq0fMtsW8gQRlnNX22h 1fQdo/RMFb4NlJ0NJxJFLhkf+51lUh8nng7d1WZq6MnvUwIejUdcBBYoKfu8vedVY7 UpR0Z0D0EKn3Q993vDnoUOWHYEYzYQBJqcmcRvGUeIXrtz0ITCbQDCCwbnMUrH09wO cd3hPQbNtKazw== 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 1xKagx-00000006kav-2zdA; Sat, 24 Oct 2026 12:17:43 +0000 Date: Sat, 24 Oct 2026 13:21:00 +0100 Message-ID: <87se1v8f2r.wl-maz@kernel.org> From: Marc Zyngier To: Amir Noohi Cc: Thomas Gleixner , Oliver Upton , Radu Rendec , Igor Velkov , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Mark Rutland , Christoffer Dall , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] genirq/manage: Provide irq_set_percpu_irqchip_state() In-Reply-To: <20261024022450.629980-2-amirmnoohi@gmail.com> References: <20261024022450.629980-1-amirmnoohi@gmail.com> <20261024022450.629980-2-amirmnoohi@gmail.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) X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list 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: amirmnoohi@gmail.com, tglx@kernel.org, oupton@kernel.org, radu@rendec.net, iav@iav.lv, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, cdall@linaro.org, kvmarm@lists.linux.dev, 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 Sat, 24 Oct 2026 03:24:49 +0100, Amir Noohi wrote: > > irq_set_irqchip_state() acquires the bus lock and the descriptor lock of > the interrupt. A per CPU devid interrupt has a single descriptor for all > CPUs, while its irqchip state is per CPU, e.g. each GICv3 redistributor > holds the active and pending state of the PPIs of its own CPU and GICv5 > keeps that state in per CPU system registers. Callers which modify that > state have to be pinned to the CPU anyway, so the descriptor lock only > serializes CPUs which update their own private state. > > KVM on arm64 sets the active state of the host timer interrupts on every > vCPU load, i.e. on every KVM_RUN ioctl and every time a vCPU thread is > scheduled in. When many CPUs load vCPUs at the same time, they all spin > on the descriptor lock of the same interrupt, even when every vCPU has > a physical CPU of its own. A global serialization point on the same path > was removed before in commit 64b6d1d7a845 ("genirq: Get rid of global > lock in irq_do_set_affinity()"). > > Provide irq_set_percpu_irqchip_state(), which sets the irqchip state of > a per CPU devid interrupt on the calling CPU without acquiring the > descriptor lock. The irqchip callback is still invoked with interrupts > disabled. The caller has to have preemption disabled and has to ensure > that the interrupt is neither freed nor reconfigured concurrently, which > is the case for an interrupt it has requested. Interrupt chips which > require a bus lock are rejected, as the bus lock may sleep and cannot be > taken with preemption disabled. > > The function is not exported as its only user, KVM on arm64, cannot be > built as a module. > > Signed-off-by: Amir Noohi > --- > include/linux/interrupt.h | 2 ++ > kernel/irq/manage.c | 36 ++++++++++++++++++++++++++++++++++++ > 2 files changed, 38 insertions(+) > > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h > index 3bf969ad8fe0..ab20129615d4 100644 > --- a/include/linux/interrupt.h > +++ b/include/linux/interrupt.h > @@ -507,6 +507,8 @@ extern int irq_get_irqchip_state(unsigned int irq, enum irqchip_irq_state which, > bool *state); > extern int irq_set_irqchip_state(unsigned int irq, enum irqchip_irq_state which, > bool state); > +int irq_set_percpu_irqchip_state(unsigned int irq, enum irqchip_irq_state which, > + bool state); > > #ifdef CONFIG_IRQ_FORCED_THREADING > # ifdef CONFIG_PREEMPT_RT > diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c > index bdb47837c66f..e76fe1cec9fb 100644 > --- a/kernel/irq/manage.c > +++ b/kernel/irq/manage.c > @@ -2777,6 +2777,42 @@ int irq_set_irqchip_state(unsigned int irq, enum irqchip_irq_state which, bool v > } > EXPORT_SYMBOL_GPL(irq_set_irqchip_state); > > +/** > + * irq_set_percpu_irqchip_state - Set the irqchip state of a per CPU interrupt > + * @irq: Linux interrupt number of a per CPU devid interrupt > + * @which: State to be set (one of IRQCHIP_STATE_*) > + * @val: Value corresponding to @which > + * > + * Variant of irq_set_irqchip_state() which sets the state of the calling > + * CPU's instance of a per CPU devid interrupt without acquiring the > + * interrupt descriptor lock. The descriptor and its lock are shared by all > + * CPUs while the state is not, so acquiring the lock only serializes CPUs > + * which modify their own state. > + * > + * Must be called with preemption disabled on an interrupt which has been > + * requested, so that the interrupt chip hierarchy cannot change > + * concurrently. Interrupt chips which require a bus lock are not supported. > + * > + * Return: 0 on success, a negative error code otherwise. > + */ > +int irq_set_percpu_irqchip_state(unsigned int irq, enum irqchip_irq_state which, bool val) > +{ > + struct irq_desc *desc = irq_to_desc(irq); > + struct irq_chip *chip; > + > + lockdep_assert_preemption_disabled(); > + > + if (WARN_ON_ONCE(!desc || !irq_settings_is_per_cpu_devid(desc))) > + return -EINVAL; > + > + chip = irq_desc_get_chip(desc); > + if (WARN_ON_ONCE(chip->irq_bus_lock || chip->irq_bus_sync_unlock)) > + return -EINVAL; > + > + guard(irqsave)(); > + return __irq_set_irqchip_state(desc, which, val); > +} > + > /** > * irq_has_action - Check whether an interrupt is requested > * @irq: The linux irq number It really feels like a leap of faith. There is nothing that says that it is safe to call this without holding the global lock. For all we know, drivers have been relying on it for a good decade, and I don't feel confident letting things rip just because it (mostly) works with the GIC. At the very least, something exposed by the irqchip (a per-IRQ flag?) should tell you whether it is safe to elide the lock. Thanks, M. -- Jazz isn't dead. It just smells funny.