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

[Salil Mehta via <qemu-devel@nongnu.org>]

> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Tuesday, October 14, 2025 4:24 PM
> To: Salil Mehta <salil.mehta@huawei.com>
> 
> On Tue, 14 Oct 2025 at 16:13, Salil Mehta <salil.mehta@huawei.com> wrote:
> >
> > > From: Peter Maydell <peter.maydell@linaro.org> In what situation do
> > > we ever start running a VCPU before the *GIC* has been realized? The
> > > GIC should get realized as part of creating the virt board, which
> > > must complete before we do anything like running a vcpu.
> >
> >
> > Just after realization of vCPU in the machvirt_init() you can see the
> > default power_state is PSCI CPU_ON, which means
> KVM_MP_STATE_RUNNABLE.
> > Since, the thread is up and not doing IO wait in userspace it gets
> > into
> > cpu_exec() loop and actually run KVM_RUN IOCTL. Inside the KVM it
> > momentarily takes the vCPU mutex but later exit and releases. This
> > keeps going on for all of the vCPU threads realized early.
> 
> Yikes. We definitely should fix that : letting the vcpu run before we get to
> qemu_machine_creation_done() seems like it would be a massive source of
> race conditions.

I've already proposed fix for this by parking such threads in userspace. Please
check functions virt_(un)park_cpu_in_userspace(). But need to check if we can use
this trick can be used at the very early stages of the VM initialization.

https://lore.kernel.org/qemu-devel/20251001010127.3092631-18-salil.mehta@opnsrc.net/


I also think we need 1:1 mapping between the ARMCPU power-state and the
KVM MP_STATE.  Right now,

KVM_MP_STATE_RUNNABLE = {PSCI CPU_OFF, PSCI CPU_ON}
KVM_MP_STATE_STOPPED    = {PSCI CPU_OFF}

KVM MP State RUNNABLE seems ambiguous. Should we use PSCI CPU_PENDING at
early stages instead?


Thanks!

Best regards
Salil.