From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLUW1-0007lO-BY for qemu-devel@nongnu.org; Fri, 08 Jul 2016 08:04:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLUVx-0005xl-3Q for qemu-devel@nongnu.org; Fri, 08 Jul 2016 08:04:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33555) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLUVw-0005xh-Ro for qemu-devel@nongnu.org; Fri, 08 Jul 2016 08:04:13 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 33BE780086 for ; Fri, 8 Jul 2016 12:04:12 +0000 (UTC) Date: Fri, 8 Jul 2016 14:04:23 +0200 From: Peter Krempa Message-ID: <20160708120423.GC78006@andariel.pipo.sk> References: <417b83d0e074e2004aa35bef337d32ac2c89f559.1467904342.git.pkrempa@redhat.com> <20160708135458.53b8214a@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160708135458.53b8214a@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 2/2] numa: Add node_id data in query-hotpluggable-cpus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: qemu-devel@nongnu.org, dgibson@redhat.com On Fri, Jul 08, 2016 at 13:54:58 +0200, Igor Mammedov wrote: > On Thu, 7 Jul 2016 17:17:14 +0200 > Peter Krempa wrote: > > > Add a helper that looks up the NUMA node for a given CPU and use it to > > fill the node_id in the PPC and X86 impls of query-hotpluggable-cpus. > > > > Signed-off-by: Peter Krempa > > --- > > hw/i386/pc.c | 7 +++++++ > > hw/ppc/spapr.c | 8 ++++++-- > > include/sysemu/numa.h | 1 + > > numa.c | 13 +++++++++++++ > > 4 files changed, 27 insertions(+), 2 deletions(-) > > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c > > index 4ba02c4..a0b9507 100644 > > --- a/hw/i386/pc.c > > +++ b/hw/i386/pc.c > > @@ -2115,6 +2115,7 @@ static HotpluggableCPUList *pc_query_hotpluggable_cpus(MachineState *machine) > > HotpluggableCPUList *head = NULL; > > PCMachineState *pcms = PC_MACHINE(machine); > > const char *cpu_type; > > + int node_id; > > > > cpu = pcms->possible_cpus->cpus[0].cpu; > > assert(cpu); /* BSP is always present */ > > @@ -2138,6 +2139,12 @@ static HotpluggableCPUList *pc_query_hotpluggable_cpus(MachineState *machine) > > cpu_props->core_id = topo.core_id; > > cpu_props->has_thread_id = true; > > cpu_props->thread_id = topo.smt_id; > > + > > + if ((node_id = numa_node_get_by_cpu_index(i)) >= 0) { > > + cpu_props->has_node_id = true; > > + cpu_props->node_id = node_id; > > + } > I've not included node_id for a reason, > "-numa cpus=1,2,3..." looks to me hopelessly broken now but > I've not came up with an idea how to redo it in nice and clean way yet. > > Alternative could be CLI-less numa configuration, where QEMU is started > without "-numa cpus" but with "-S" then mgmt could call > query_hotpluggable_cpus() to get possible CPUs and then > map them to numa nodes with a new QMP command using attributes > it got from query_hotpluggable_cpus(). I think this could work for libvirt. The CPU index we currently expose in the XML would become just a libvirt internal detail and the new QMP command would be used to do the setup. Adding some QMP calls during VM startup is okay. > it's along the way start QEMU -smp 1,maxcpus=X and then add > remaining CPUs with device_add after getting properties from > query_hotpluggable_cpus(). I'm going to use a similar approach even for the hotpluggable cpus so I can query the data for a new VM. On the other hand I can't make libvirt use the approach with -smp 1,... all the time since we guarantee that a XML that worked on a older version will be migratable back to the older version. > then at machine_done time we can adjust DT/ACPI data to reflect > configured mapping. In such case this series can be dropped since it provides what I need differently. Thanks, Peter