From: sashiko-bot@kernel.org
To: "Sascha Bischoff" <Sascha.Bischoff@arm.com>
Cc: "Oliver Upton" <oupton@kernel.org>,
"Marc Zyngier" <maz@kernel.org>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH 3/5] irqchip/gic-v5: Synchronize CPU interface disable
Date: Mon, 10 Aug 2026 10:54:39 +0000 [thread overview]
Message-ID: <20260810105440.17CBA1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260810102652.758719-4-sascha.bischoff@arm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but it leaves critical architectural violations unaddressed due to a misunderstanding of ARM64 requirements (as noted in the commit message). Missing mandatory `isb()` instructions immediately after writing to control-plane system registers (`ICC_*_EL1`). The ARM64 architecture subsystem guidelines mandate that every write to a control-plane system register MUST be followed by an `isb()` as the very next instruction. The `isb()` synchronizes the local CPU pipeline; it does not wait for external interrupt delivery. The patch author explicitly omitted an `isb()` after writing to `SYS_ICC_CR0_EL1` in `gicv5_cpu_enable_interrupts()`, claiming 'interrupt delivery is asynchronous'. Furthermore, there are preexisting violations across multiple functions (`gicv5_cpu_enable_interrupts()`, `gicv5_ppi_priority_init()`, and `write_ppi_sysreg_s()`) where writes to `ICC_*_EL1` registers are batched with intervening instructions before an eventual `isb()`, or lack one entirely.
--
--- Patch [3]: [PATCH 3/5] irqchip/gic-v5: Synchronize CPU interface disable ---
commit 55c441d845df8718ca0aac7ff0ab6a4a351c19dc
Author: Sascha Bischoff <Sascha.Bischoff@arm.com>
irqchip/gic-v5: Synchronize CPU interface disable
This commit adds a missing ISB instruction after the ICC_CR0_EL1 write in
gicv5_cpu_disable_interrupts() to ensure interrupts are disabled before
the function returns.
Link: https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=6
> Add an ISB after the ICC_CR0_EL1 write to ensure interrupts are
> disabled before the function returns. No corresponding ISB is added
> when enabling the interface, as interrupt delivery is asynchronous and
> there is no obvious benefit to waiting for it.
[Severity: High]
This isn't a bug introduced by this patch, but does omitting the ISB
leave the CPU pipeline in an undefined state?
The ARM64 architecture requires an isb() immediately after writing to
control-plane system registers like ICC_*_EL1 to synchronize the local CPU
pipeline, not just to wait for external interrupt delivery.
> diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
> index e9d1795235a66..6a99c541b559b 100644
> --- a/drivers/irqchip/irq-gic-v5.c
> +++ b/drivers/irqchip/irq-gic-v5.c
> @@ -983,6 +983,7 @@ static void gicv5_cpu_disable_interrupts(void)
>
> cr0 = FIELD_PREP(ICC_CR0_EL1_EN, 0);
> write_sysreg_s(cr0, SYS_ICC_CR0_EL1);
> + isb();
> }
>
> static void gicv5_cpu_enable_interrupts(void)
[Severity: High]
This is a pre-existing issue, but should gicv5_cpu_enable_interrupts()
and other related functions also be updated to include the mandatory isb()
instructions?
For example, in gicv5_cpu_enable_interrupts(), writes to registers like
SYS_ICC_PPI_ENABLER0_EL1 and SYS_ICC_CR0_EL1 lack an immediate isb()
after each write.
Similarly, are the batched writes in gicv5_ppi_priority_init() and the
state updates in write_ppi_sysreg_s() missing their required isb()
synchronizations before returning?
Placing a return instruction or intervening instructions before an isb()
can cause the CPU to observe undefined pipeline state.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260810102652.758719-1-sascha.bischoff@arm.com?part=3
next prev parent reply other threads:[~2026-08-10 10:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 10:27 [PATCH 0/5] arm64: gic-v5: Fixes from GICv5 KVM IRS review Sascha Bischoff
2026-08-10 10:27 ` [PATCH 1/5] KVM: arm64: vgic: Free gic_kvm_info on initialization failure Sascha Bischoff
2026-08-10 10:28 ` [PATCH 2/5] irqchip/gic-v5: Clear per-CPU IRS data on teardown Sascha Bischoff
2026-08-10 10:47 ` sashiko-bot
2026-08-10 11:45 ` Lorenzo Pieralisi
2026-08-10 11:36 ` Lorenzo Pieralisi
2026-08-11 15:03 ` Sascha Bischoff
2026-08-10 10:28 ` [PATCH 3/5] irqchip/gic-v5: Synchronize CPU interface disable Sascha Bischoff
2026-08-10 10:54 ` sashiko-bot [this message]
2026-08-11 14:55 ` Sascha Bischoff
2026-08-10 10:29 ` [PATCH 4/5] KVM: arm64: vgic: Prevent speculative SPI array underflow Sascha Bischoff
2026-08-10 10:29 ` [PATCH 5/5] KVM: arm64: vgic: Reject out-of-range GICv5 PPI IDs Sascha Bischoff
2026-08-10 11:16 ` sashiko-bot
2026-08-11 14:59 ` Sascha Bischoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260810105440.17CBA1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Sascha.Bischoff@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.