From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ki7ZX-0000oy-IR
	for qemu-devel@nongnu.org; Tue, 23 Sep 2008 09:04:55 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ki7ZV-0000oc-9o
	for qemu-devel@nongnu.org; Tue, 23 Sep 2008 09:04:54 -0400
Received: from [199.232.76.173] (port=46299 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ki7ZV-0000oZ-54
	for qemu-devel@nongnu.org; Tue, 23 Sep 2008 09:04:53 -0400
Received: from mail.codesourcery.com ([65.74.133.4]:56375)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1Ki7ZU-00084t-Ft
	for qemu-devel@nongnu.org; Tue, 23 Sep 2008 09:04:52 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [patch] move MAX_CPUS to cpu.h
Date: Tue, 23 Sep 2008 14:04:48 +0100
References: <48D8D694.1000609@sgi.com>
	<200809231350.34178.paul@codesourcery.com>
	<48D8E6CA.9040802@sgi.com>
In-Reply-To: <48D8E6CA.9040802@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200809231404.49340.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jes Sorensen <jes@sgi.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org

On Tuesday 23 September 2008, Jes Sorensen wrote:
> Paul Brook wrote:
> > On Tuesday 23 September 2008, Jes Sorensen wrote:
> >> Paul> Anything using the value to allocate per-cpu structures will be
> >> Paul> wrong.
> >>
> >> What do you mean? There's plenty places where you will want to only
> >> allocate enough space for the number of cpus you want to support.
> >
> > Some ARM boards have 4 cpus, they just don't use the -smp option.
>
> So what you're saying is that we need to distinguish between number of
> possible CPUs and how many we allow for a given type of emulation? It
> seems to me that using MAX_CPUS to be the maximum possible for an
> architecture is fair and we should then maybe put it into the machine
> description to set the upper limit for actual runtime ones?

Something like that, yes.

Currently there's no real hard limit on the number of CPUs. I'd be nice to 
keep it that way if possible.

Paul