From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLUrl-0001Rn-IE for qemu-devel@nongnu.org; Fri, 08 Jul 2016 08:26:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLUre-000242-BJ for qemu-devel@nongnu.org; Fri, 08 Jul 2016 08:26:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44251) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLUre-00023v-5p for qemu-devel@nongnu.org; Fri, 08 Jul 2016 08:26:38 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (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 9C00B64076 for ; Fri, 8 Jul 2016 12:26:37 +0000 (UTC) Date: Fri, 8 Jul 2016 14:26:48 +0200 From: Peter Krempa Message-ID: <20160708122648.GD78006@andariel.pipo.sk> References: <417b83d0e074e2004aa35bef337d32ac2c89f559.1467904342.git.pkrempa@redhat.com> <20160708122308.1f43b56a@voom.fritz.box> <20160708074600.GB78006@andariel.pipo.sk> <20160708140631.6562c90c@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160708140631.6562c90c@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: David Gibson , qemu-devel@nongnu.org On Fri, Jul 08, 2016 at 14:06:31 +0200, Igor Mammedov wrote: > On Fri, 8 Jul 2016 09:46:00 +0200 > Peter Krempa wrote: > > [...] > > Note: For libvirt it's a no-go to start a throwaway qemu process just to > > query the information and thus it's desired to have a way to configure > > all this without the need to query with a specific machine > > type/topology. > Is it no-go to start throwaway qemu on the new domain creation time? Yes. The policy is that once we are starting the VM the qemu process that we create is the one running the VM later. We can tweak stuff using QMP and/or kill it if the configuration requested by the user can't be achieved, but starting a different qemu process would not be accepted upstream. Capability querying is done prior to that with a qemu process with -M none and the results are cached for the given combination of qemu binary and libvirtd binary (even across restarts of the libvirtd binary). > i.e. user create a new domain, with specific -machine/-smp layout > libvirt stores results of query-hotpluggable-cpus and then allow user > in (eg)virt-manager to pick which CPUs are enabled and optionally to > which numa nodes they are mapped. We can update certain stuff that was not explicitly configured by the user to the state that will then be used by qemu.