Re: [PATCH] hw/intc/arm_gicv3_kvm: Avoid reading ICC_CTLR_EL1 from kernel in cpuif reset

[Salil Mehta <salil.mehta@opnsrc.net>]

On Thu, Oct 16, 2025 at 12:23 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 16 Oct 2025 at 13:17, Salil Mehta <salil.mehta@huawei.com> wrote:
> >
> > Hi Peter,
> >
> > > From: qemu-devel-bounces+salil.mehta=huawei.com@nongnu.org <qemu-
> > > devel-bounces+salil.mehta=huawei.com@nongnu.org> On Behalf Of Peter
> > > Maydell
> > > Sent: Tuesday, October 14, 2025 11:25 AM
> > > To: qemu-devel@nongnu.org
> > > Cc: Salil Mehta <salil.mehta@opnsrc.net>; Marc Zyngier <maz@kernel.org>
> > > Subject: [PATCH] hw/intc/arm_gicv3_kvm: Avoid reading ICC_CTLR_EL1 from
> > > kernel in cpuif reset
> > >
> > > Currently in arm_gicv3_icc_reset() we read the kernel's value of
> > > ICC_CTLR_EL1 as part of resetting the CPU interface.  This mostly works, but
> > > we're actually breaking an assumption the kernel makes that userspace only
> > > accesses the in-kernel GIC data when the VM is totally paused, which may
> > > not be the case if a single vCPU is being reset.  The effect is that it's possible
> > > that the read attempt returns EBUSY.
> > >
> > > Avoid this by reading the kernel's value of the reset ICC_CTLR_EL1 once in
> > > device realize. This brings ICC_CTLR_EL1 into line with the other cpuif
> > > registers, where we assume we know what the kernel is resetting them to
> > > and just update QEMU's data structures in arm_gicv3_icc_reset().
> > >
> > > Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> > > ---
> > > I've only tested this fairly lightly, but it seems to work.
> > > Salil, does this fix the EBUSY issues you were seeing ?
> >
> >
> > Would you be absorbing this in your tree now or should I make it part
> > of the RFC V7 ?
> >
> > Reviewed-by: Salil Mehta <salil.mehta@huawei.com>
> > Tested-by: Salil Mehta <salil.mehta@huawei.com>
>
> Thanks for the testing. I'll pull it into target-arm.next since
> it does fix a potential issue with the current codebase.


Thanks. I hope you've noticed my earlier reply. There is a potential
*future* breakdown condition with this patch.

https://lore.kernel.org/qemu-devel/e2b03da8f7514b57aef7d236be1dcb90@huawei.com/

I assume you've accepted that as a no-risk?


Best regards
Salil.


>
> -- PMM