> From: Peter Maydell <[email protected]> > Sent: Tuesday, October 14, 2025 4:24 PM > To: Salil Mehta <[email protected]> > > On Tue, 14 Oct 2025 at 16:13, Salil Mehta <[email protected]> wrote: > > > > > From: Peter Maydell <[email protected]> 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/[email protected]/ 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.
