RE: [RFC PATCH] KVM: arm64: vgic-v3: Cache ICC_CTLR_EL1 and allow lockless read when ready

[Salil Mehta <salil.mehta@huawei.com>]

Hi Peter,

> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Tuesday, October 14, 2025 10:31 AM
> 
> On Tue, 14 Oct 2025 at 04:02, Salil Mehta <salil.mehta@opnsrc.net> wrote:
> > On Mon, Oct 13, 2025 at 4:48 PM Peter Maydell
> <peter.maydell@linaro.org> wrote:
> > > That said, QEMU's current code for this could be refactored to avoid
> > > the reset-time read of ICC_CTLR_EL1 from the kernel.
> > > We do this so we can set the userspace struct field for this
> > > register to the right value. But we could ask the kernel for that
> > > value once on VM startup since it's not going to change mid-run.
> > >
> > > That would bring ICC_CTLR_EL1 into line with the other cpuif
> > > registers, where QEMU assumes it knows what the kernel's reset value
> > > of them is (mostly "0") and doesn't bother to ask.
> > > This is different from how we handle ONE_REG sysregs, where I'm
> > > pretty sure we do ask the kernel the value of all of them on a vcpu
> > > reset. (And then write the values back again, which is a bit silly
> > > but nobody's ever said it was a performance problem for them :-))
> >
> >
> > This is effectively what the mentioned patch in the commit-log is doing.
> > Pasting here again:
> >
> > https://lore.kernel.org/qemu-devel/20251001010127.3092631-22-salil.meh
> > ta@opnsrc.net/
> 
> No, that is not what I have in mind. What I mean is that we can just read the
> ICC_CTLR_EL1 value once on startup (in our realize method, I think) and then
> use that value in reset. That should not require any of that machinery to
> pause the VM and keep retrying.


Indeed and that’s what I did initially and had fetched the value once in GICv3
realize but it hung the VM initialization leg during access.

BTW, can we safely assume that value of this register will be same across all
vCPUs (i.e. is just for SMP case and ignore heterogenous)? 


Best regards
Salil


> 
> -- PMM