From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL9dX-0002AL-A8 for qemu-devel@nongnu.org; Wed, 05 Mar 2014 06:05:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WL9dP-0003Ds-Nx for qemu-devel@nongnu.org; Wed, 05 Mar 2014 06:05:19 -0500 Received: from cantor2.suse.de ([195.135.220.15]:48316 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL9dP-0003DR-Hf for qemu-devel@nongnu.org; Wed, 05 Mar 2014 06:05:11 -0500 Message-ID: <531704E2.3010406@suse.de> Date: Wed, 05 Mar 2014 12:05:06 +0100 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1393941656-29068-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1393941656-29068-1-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2.1 00/28] Current state of NUMA series, and hostmem improvements List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org, Chen Fan Cc: ehabkost@redhat.com, hutao@cn.fujitsu.com, mtosatti@redhat.com, imammedo@redhat.com, a.motakis@virtualopensystems.com, gaowanlong@cn.fujitsu.com Am 04.03.2014 15:00, schrieb Paolo Bonzini: > This series includes all the pending work on QOMifying the memory > backends. [snip] There's also a recent RFC from Chen Fan about how to model the association between NUMA nodes and CPU socket/core/thread that would/should influence this series if we're aiming for 2.1 now. I didn't review it in-depth yet, but minor technical issues apart, I think we need to keep NUMA and CPU separate, which then brings up the question Chen Fan asked about whether we need to support splitting CPU threads of one core or CPU cores of one socket onto different NUMA nodes. If we can stop supporting this, 2.0 would be a good point in time to catch this with an error message at least, even if the remodeling depending on it happens post-2.0. For example, assuming associativity at CPU socket level, I'd imagine: /machine /numa-node[0] cpu[0] -> /machine/unassigned/device[0] /unassigned /device[0] /core[0] /thread[0] I.e. the CPU socket is a self-contained object in /machine/unassigned when machine-created or in /machine/peripheral when device_add'ed. Hotplug will need a link<> property somewhere, and for a standard PC this can be on /machine (Qseven modules, SoCs etc. would require it a level down on their container but we don't support those yet). Having the links on the NUMA nodes corresponds to having multiple buses in the qdev world. Compare that to: /machine /node[0] # This is not really telling! /socket[0] /core[0] /thread[0] # So CPUState !=3D thread? cpu -> /machine/unassigned/device[0] /unassigned /device[0] Note that according to my interpretation of QOM ABI stability rules we can't just turn a link into a child without renaming, thus trying to be forward-looking for where we want to go design-wise. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg