Re: [PATCH v1 3/4] KVM: arm64: vgic: Do not access the GICv5 CPU interface from EL1
Fuad Tabba <[email protected]> Thu, 6 Aug 2026 11:28:23 +0100
| Newsgroups | dev.linux.lists.kvmarm,dev.linux.lists.sashiko-reviews |
|---|---|
| Message-ID | <CA+EHjTxNyzw_t++nF66zocB2de5ZKwtAN4M9jj69VU457OEMFA@mail.gmail.com> |
On Thu, 6 Aug 2026 at 11:16, <[email protected]> wrote: > > 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. This runs on the guest-entry path, and the ERET into the guest is a context synchronization event. I really thought we've covered this in the review-prompts, I'll look into this later... /fuad > -- > > --- Patch [3]: [PATCH v1 3/4] KVM: arm64: vgic: Do not access the GICv5 CPU interface from EL1 --- > commit 5b0cdbb37754741e9006b6abdf408b239ed6b887 > Author: Fuad Tabba <[email protected]> > > 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/[email protected]?part=3