On 2012-10-05 11:28, Ronald Hecht wrote: > Hello all, > > I have a question regarding LEON SPARC SMP. In a LEON SPARC SMP system > secondary CPUs (others that CPU#0) can be started by setting certain > bits in the interrupt controller. At startup (reset) all CPUs are halted > except CPU#0. In QEMU version 0.12 it was possible to simply set > CPUSPARCState.halted to "0" to start a secondary CPU. This is no longer > possible and reliable. The CPU that should be started does not wake up > by doing this: > > env->halted = 0; > qemu_cpu_kick(env); > > It seems that the running CPU blocks the startup of the halted CPU. I > need to notice, that the halted CPU has interrupts (and traps) disabled > at startup. Thus, it is not possible to start the CPU by raising an > interrupt. > > I was playing with several things and I found that doing > > env->halted = 0; > qemu_cpu_kick(env);
qemu_cpu_kick is basically a nop when issued over the TCG thread. > cpu_exit(cpu_single_env); > > helps. The statement cpu_exit(cpu_single_env) forces the current CPU > (cpu_single_env) to exit the execution loop and which allows to start > the other CPU (env). > > I'm unsure if this is the correct way to solve my problem. Any comments > on this? SMP CPU "scheduling" is conceptually broken in QEMU when using TCG. It happens to work most of the time because unrelated I/O events (including timers) force the VCPU thread to leave and, thus, to reschedule afterward. This breaks of course in the absence of events. And you may face such a scenario here. The best solution long term (until we can thread TCG VCPUs) would be to set up a timer over the TCG thread and use that one to schedule (unless a VCPU goes to halt or starts to spin on a typical lock pattern). For now, an explicit "rescheduling point" via cpu_exit is indeed the way to go. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux