qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]