From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK5PS-0005Bq-M1 for qemu-devel@nongnu.org; Fri, 05 Oct 2012 06:45:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TK5PR-0003m0-7V for qemu-devel@nongnu.org; Fri, 05 Oct 2012 06:45:34 -0400 Received: from goliath.siemens.de ([192.35.17.28]:15898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TK5PQ-0003kM-Tn for qemu-devel@nongnu.org; Fri, 05 Oct 2012 06:45:33 -0400 Message-ID: <506EBA43.1000002@siemens.com> Date: Fri, 05 Oct 2012 12:45:23 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <506EA82A.3070301@gmx.de> In-Reply-To: <506EA82A.3070301@gmx.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC] Starting a (secondary) CPU when it is halted or reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ronald Hecht Cc: qemu-devel@nongnu.org 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