From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ki7fD-000243-Gz
	for qemu-devel@nongnu.org; Tue, 23 Sep 2008 09:10:47 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ki7fC-00023h-4g
	for qemu-devel@nongnu.org; Tue, 23 Sep 2008 09:10:47 -0400
Received: from [199.232.76.173] (port=37366 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ki7fB-00023a-Ui
	for qemu-devel@nongnu.org; Tue, 23 Sep 2008 09:10:45 -0400
Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:55808
	helo=relay.sgi.com) by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <jes@sgi.com>) id 1Ki7fB-0002Os-JC
	for qemu-devel@nongnu.org; Tue, 23 Sep 2008 09:10:45 -0400
Message-ID: <48D8EAD2.9030709@sgi.com>
Date: Tue, 23 Sep 2008 15:10:42 +0200
From: Jes Sorensen <jes@sgi.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [patch] move MAX_CPUS to cpu.h
References: <48D8D694.1000609@sgi.com>
	<200809231350.34178.paul@codesourcery.com>
	<48D8E6CA.9040802@sgi.com>
	<200809231404.49340.paul@codesourcery.com>
In-Reply-To: <200809231404.49340.paul@codesourcery.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Paul Brook <paul@codesourcery.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org

Paul Brook wrote:
> On Tuesday 23 September 2008, Jes Sorensen wrote:
>> 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.

Hmmmm I'll take a look and see what I can come up with. The machine
struct seems the right place for the runtime limit I think.

I think realistically speaking there will be hard limits on CPUs, but we
can put them at reasonable limits (most people, except for me, would
probably not complain being capped at 256 :-). It's of course possible
to completely get rid of long term, but there could be issues with
runtime allocation cost in hot paths.

Cheers,
Jes