From: sashiko-bot@kernel.org
To: "Fuad Tabba" <fuad.tabba@linux.dev>
Cc: kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>,
"Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH v1 3/4] KVM: arm64: vgic: Do not access the GICv5 CPU interface from EL1
Date: Thu, 06 Aug 2026 10:15:58 +0000 [thread overview]
Message-ID: <20260806101600.207261F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806100256.371164-4-fuad.tabba@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing Context Synchronization Event (CSE) after writing to SYS_ICC_ICSR_EL1.
--
--- Patch [3]: [PATCH v1 3/4] KVM: arm64: vgic: Do not access the GICv5 CPU interface from EL1 ---
commit 5b0cdbb37754741e9006b6abdf408b239ed6b887
Author: Fuad Tabba <fuad.tabba@linux.dev>
KVM: arm64: vgic: Do not access the GICv5 CPU interface from EL1
This commit fixes an issue where the GICv5 CPU interface was incorrectly
accessed from EL1 on systems without FEAT_GCIE_LEGACY. It restricts GICv5
access to VHE, similar to the existing GICv3 handling.
> diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
> index 74bace10a22ed..df58c0042ed63 100644
> --- a/arch/arm64/kvm/vgic/vgic.c
> +++ b/arch/arm64/kvm/vgic/vgic.c
> @@ -1042,11 +1042,15 @@ static void vgic_flush_lr_state(struct kvm_vcpu *vcpu)
> static inline bool can_access_vgic_from_kernel(void)
> {
> /*
> - * GICv2 can always be accessed from the kernel because it is
> - * memory-mapped, and VHE systems can access GICv3 EL2 system
> - * registers.
> + * GICv3 and GICv5 drive the CPU interface through EL2 system
> + * registers, so only VHE reaches them from the kernel. GICv2 is
> + * memory-mapped and always reachable.
> */
> - return !static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif) || has_vhe();
> + if (kvm_vgic_global_state.type == VGIC_V5 ||
> + static_branch_unlikely(&kvm_vgic_global_state.gicv3_cpuif))
> + return has_vhe();
> +
> + return true;
> }
While reviewing the GICv5 access paths related to this change, I noticed a
related issue in the GICv5 context restore path:
arch/arm64/kvm/hyp/vgic-v5-sr.c:__vgic_v5_restore_state() {
write_sysreg_s(cpu_if->vgic_icsr, SYS_ICC_ICSR_EL1);
}
[Severity: High]
This isn't a bug introduced by this patch, but does this write to
SYS_ICC_ICSR_EL1 require a subsequent isb() instruction?
According to the ARM64 KVM architectural rules, any write to an ICC_*_EL1
register (excluding ICC_PMR_EL1) must be immediately followed by an isb()
as the very next instruction.
Because __vgic_v5_restore_state() writes to SYS_ICC_ICSR_EL1 and then
returns, the caller will execute subsequent instructions without a Context
Synchronization Event. Could this leave the CPU operating with an
architecturally undefined pipeline state during the vCPU switch?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260806100256.371164-1-fuad.tabba@linux.dev?part=3
next prev parent reply other threads:[~2026-08-06 10:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 10:02 [PATCH v1 0/4] KVM: arm64: Fix unguarded GICv5 CPU interface accesses Fuad Tabba
2026-08-06 10:02 ` [PATCH v1 1/4] KVM: arm64: Validate the host-provided vgic model in pKVM Fuad Tabba
2026-08-06 10:32 ` sashiko-bot
2026-08-06 10:40 ` Fuad Tabba
2026-08-07 9:56 ` Sascha Bischoff
2026-08-07 10:14 ` Fuad Tabba
2026-08-06 10:02 ` [PATCH v1 2/4] KVM: arm64: Reject the GICv5 CPU interface hypercalls under pKVM Fuad Tabba
2026-08-06 10:20 ` sashiko-bot
2026-08-06 10:36 ` Fuad Tabba
2026-08-06 10:02 ` [PATCH v1 3/4] KVM: arm64: vgic: Do not access the GICv5 CPU interface from EL1 Fuad Tabba
2026-08-06 10:15 ` sashiko-bot [this message]
2026-08-06 10:28 ` Fuad Tabba
2026-08-06 10:02 ` [PATCH v1 4/4] KVM: arm64: Fix stale VGICv3 comments in the nVHE world switch Fuad Tabba
2026-08-07 10:07 ` [PATCH v1 0/4] KVM: arm64: Fix unguarded GICv5 CPU interface accesses 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=20260806101600.207261F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fuad.tabba@linux.dev \
--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.