From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KlQN8-0006sx-8N
	for qemu-devel@nongnu.org; Thu, 02 Oct 2008 11:45:46 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KlQN4-0006s3-7P
	for qemu-devel@nongnu.org; Thu, 02 Oct 2008 11:45:45 -0400
Received: from [199.232.76.173] (port=42936 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KlQN3-0006ry-Vs
	for qemu-devel@nongnu.org; Thu, 02 Oct 2008 11:45:42 -0400
Received: from mail.codesourcery.com ([65.74.133.4]:46642)
	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 1KlQN3-0004lj-1k
	for qemu-devel@nongnu.org; Thu, 02 Oct 2008 11:45:41 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [patch] Introduce per machine based max_cpu variable
Date: Thu, 2 Oct 2008 16:45:34 +0100
References: <48D8D694.1000609@sgi.com>
	<200809231404.49340.paul@codesourcery.com>
	<48DBAC61.9090906@sgi.com>
In-Reply-To: <48DBAC61.9090906@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200810021645.35683.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: qemu-devel@nongnu.org
Cc: Anthony Liguori <aliguori@us.ibm.com>, Jes Sorensen <jes@sgi.com>

> Here's an attempt of implementing a per-machine max_cpus variable.
> This means developers can limit smp support to match the actual board
> sizes. It also makes the static MAX_CPUS check in vl.c obsolete which
> I think is a good thing :-)

This looks reasonable, but is still not an ideal solution.  It is an 
improvement over what we currently have, so I'm not going to object to it 
being applied.

The maximum number of CPUs may be a property of the CPU, not the board.  
Especially in the embedded world it's becoming common to have multicore CPUs 
connected to dumb single socket systems/boards.

IMHO max_cpus should be the actual number of cpus, not N-1 as has been 
suggested elsewhere in this thread.  It may be ok to accept max_cpus==0 as a 
special case meaning max_cpus==1 to avoid having to change all the machine 
descriptions. Probably less confusing to just make all the changes you 
suggested though.

Paul