[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Starting a (secondary) CPU when it is halted or r
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [RFC] Starting a (secondary) CPU when it is halted or reset |
Date: |
Fri, 05 Oct 2012 12:45:23 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
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