Re: [PATCH v4 46/48] KVM: selftests: Add VGICv5 SPI injection tests

Sascha Bischoff <[email protected]> Fri, 31 Jul 2026 14:54:19 +0000
Newsgroups dev.linux.lists.sashiko-reviews,dev.linux.lists.kvmarm,org.kernel.vger.kvm
Message-ID <[email protected]>
On Fri, 2026-07-24 at 12:15 +0000, [email protected] wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> - [Medium] Writes to GICv5 control-plane system registers are missing
> the mandatory immediate isb() synchronization.
> --
> 
> --- Patch [46]: [PATCH v4 46/48] KVM: selftests: Add VGICv5 SPI
> injection tests ---
> commit 194658b92777c0e76e825f04069b3e506ee164f3
> Author: Sascha Bischoff <[email protected]>
> 
> KVM: selftests: Add VGICv5 SPI injection tests
> 
> Add VGICv5 SPI delivery coverage through KVM_IRQ_LINE. SPIs are
> configured through the virtual IRS and delivered through the GICv5
> CPU
> interface, so the test needs to exercise both the userspace injection
> path and the guest-side IRS programming path.
> 
> > diff --git a/tools/testing/selftests/kvm/arm64/vgic_v5.c
> > b/tools/testing/selftests/kvm/arm64/vgic_v5.c
> > index 22ae726b17be8..cec994a77c993 100644
> > --- a/tools/testing/selftests/kvm/arm64/vgic_v5.c
> > +++ b/tools/testing/selftests/kvm/arm64/vgic_v5.c
> [ ... ]
> > @@ -41,7 +44,71 @@ static struct kvm_vgic_v5_ist
> > vgic_v5_ist_attr(void *spi_ist, size_t spi_size,
> >  	};
> >  }
> >  
> > +static void gicv5_setup_and_enable_hwirq(u64 hwirq, u32
> > target_vpe)
> > +{
> > +	u64 val;
> > +
> > +	val = hwirq | FIELD_PREP(GICV5_GIC_CDPRI_PRIORITY_MASK,
> > +				 GICV5_IRQ_DEFAULT_PRI);
> > +	gic_insn(val, CDPRI);
> > +
> > +	val = hwirq | FIELD_PREP(GICV5_GIC_CDAFF_IAFFID_MASK,
> > target_vpe);
> > +	gic_insn(val, CDAFF);
> > +
> > +	gic_insn(hwirq, CDEN);
> 
> [Severity: Medium]
> Are isb() barriers required after these control-plane system register
> writes?
> 

No.

> Unless these specific GICv5 CD registers are architecturally defined
> as
> self-synchronizing, ARM64 requires an immediate isb() after every
> control-plane system register write to ensure the CPU pipeline
> observes
> the new configuration state.

These are all operating on the same interrupt to change the state of
it. This does not need explicit synchronisation.

> 
> > +}
> [ ... ]
> > +static void guest_spi_irq_handler(struct ex_regs *regs)
> > +{
> > +	bool valid;
> > +	u32 hwirq;
> > +	u64 ia;
> > +
> > +	ia = gicr_insn(CDIA);
> > +	valid = GICV5_GICR_CDIA_VALID(ia);
> > +
> > +	if (!valid)
> > +		return;
> > +
> > +	gsb_ack();
> > +	isb();
> > +
> > +	hwirq = FIELD_GET(GICV5_GICR_CDIA_INTID, ia);
> > +
> > +	GUEST_ASSERT_EQ(hwirq,
> > gicv5_spi_hwirq(READ_ONCE(spi_line_expected)));
> > +
> > +	gic_insn(hwirq, CDDI);
> > +	gic_insn(0, CDEOI);
> 
> [Severity: Medium]
> Should these system register writes also be followed by isb()
> barriers?
> 
> Similar to the above, without explicit synchronization, the pipeline
> might not immediately observe the updated state before the exception
> handler completes.

The part that needs synchronisation is the CDIA, and we have that in
the form of a gsb_ack() and isb(). The rest does not.

> 
> > +
> > +	GUEST_DONE();
> > +}
>