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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox