From: Jan Kiszka <jan.kiszka@siemens.com>
To: Ronald Hecht <ronald.hecht@gmx.de>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC] Starting a (secondary) CPU when it is halted or reset
Date: Fri, 05 Oct 2012 12:45:23 +0200 [thread overview]
Message-ID: <506EBA43.1000002@siemens.com> (raw)
In-Reply-To: <506EA82A.3070301@gmx.de>
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
prev parent reply other threads:[~2012-10-05 10:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-05 9:28 [Qemu-devel] [RFC] Starting a (secondary) CPU when it is halted or reset Ronald Hecht
2012-10-05 10:45 ` Jan Kiszka [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=506EBA43.1000002@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=qemu-devel@nongnu.org \
--cc=ronald.hecht@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.