[Qemu-devel] [RFC] Starting a (secondary) CPU when it is halted or reset

[Qemu-devel] [RFC] Starting a (secondary) CPU when it is halted or reset

[Ronald Hecht]

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);
                 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?

Thanks and best regards,
Ronald

Re: [Qemu-devel] [RFC] Starting a (secondary) CPU when it is halted or reset

[Jan Kiszka]

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