From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Klh9l-0006fh-By
	for qemu-devel@nongnu.org; Fri, 03 Oct 2008 05:41:05 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Klh9j-0006ew-3h
	for qemu-devel@nongnu.org; Fri, 03 Oct 2008 05:41:04 -0400
Received: from [199.232.76.173] (port=34132 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Klh9i-0006ep-Je
	for qemu-devel@nongnu.org; Fri, 03 Oct 2008 05:41:02 -0400
Received: from relay1.sgi.com ([192.48.171.29]:49556 helo=relay.sgi.com)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <jes@sgi.com>) id 1Klh9i-0008Ew-6B
	for qemu-devel@nongnu.org; Fri, 03 Oct 2008 05:41:02 -0400
Message-ID: <48E5E8A7.5020805@sgi.com>
Date: Fri, 03 Oct 2008 11:40:55 +0200
From: Jes Sorensen <jes@sgi.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [patch] Introduce per machine based max_cpu variable
References: <48D8D694.1000609@sgi.com>
	<200809231404.49340.paul@codesourcery.com>
	<48DBAC61.9090906@sgi.com>
	<200810021645.35683.paul@codesourcery.com>
In-Reply-To: <200810021645.35683.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:
>> 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.

Hi Paul,

Thanks for the feedback.

I don't think this patch will conflict with what you describe. I think
eventually we will want to have flags that allow the user to specify
the number of sockets and cores per socket to handle this. However I
don't know how far the QEMU system emulation layer is from being able to
actually simulate this.

Cheers,
Jes