From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37076) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGL0p-0002Dy-Em for qemu-devel@nongnu.org; Fri, 24 Jun 2016 02:54:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGL0m-0003n2-5Y for qemu-devel@nongnu.org; Fri, 24 Jun 2016 02:54:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38649) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGL0l-0003mr-Tg for qemu-devel@nongnu.org; Fri, 24 Jun 2016 02:54:44 -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 4F09E627C3 for ; Fri, 24 Jun 2016 06:54:43 +0000 (UTC) Date: Fri, 24 Jun 2016 16:56:21 +1000 From: David Gibson Message-ID: <20160624165621.243d89d0@voom.fritz.box> In-Reply-To: <20160624054111.GC545469@andariel.pipo.sk> References: <6a52d9a67cc72abb874c9906df039d11bfe1e18d.1466713052.git.pkrempa@redhat.com> <20160624125617.54dc1fc9@voom.fritz.box> <576CADC5.6020602@redhat.com> <20160624145651.16a2dbc4@voom.fritz.box> <20160624054111.GC545469@andariel.pipo.sk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/X287O8vUP25H2QFxCg/.Vbw"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [PATCH 1/3] qapi: Report support for -device cpu hotplug in query-machines List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Krempa Cc: Eric Blake , Igor Mammedov , qemu-devel@nongnu.org --Sig_/X287O8vUP25H2QFxCg/.Vbw Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 24 Jun 2016 07:41:11 +0200 Peter Krempa wrote: > On Fri, Jun 24, 2016 at 14:56:51 +1000, David Gibson wrote: >=20 > [...] >=20 > > > You are correct - query-commands says whether 'query-hotpluggable-cpu= s' > > > exists as a command. But that is insufficient. See my review, or the > > > v2 patch, where the above poor wording was corrected to say what was > > > really meant: knowing whether query-hotpluggable-cpus exists is > > > insufficient to tell you whether a given cpu type can be hotplugged. = So > > > adding one more piece of witness (for every type of cpu supported, we > > > also advertise if it is hotpluggable) is enough for libvirt to > > > efficiently take advantage of the new query-hotpluggable-cpus command= . =20 > >=20 > > Ah, right. Or to put it another way, the availability of > > query-hotpluggable-cpus is global across qemu, whereas actually being > > able to use it for hotplug is per machine type. > >=20 > > Would it be possible to do this instead by attempting to invoke > > query-hopluggable-cpus and seeing if it returns any information? =20 >=20 > It is not strictly necessary for us to have this in the context of > usability. If the user requests using the new hotplug feature we will > try it unconditionally and call query-hotpluggable-cpus before even > starting guest execution. A failure to query the state will then result > in termination of the VM. Oh.. I wasn't expecting the feature would be enabled at user request - I thought libvirt would just use it if available. > It is necessary though to report the availability of the feature to the > user via our domain capabilities API which some higher layer management > apps use to make decisions. Right... what advantage does adding the machine flag have over attempting the query-hotpluggable-cpus? > This would also be necessary if we wanted to switch by default to the > new approach, but that's not really possible as libvirt tries to > guarantee that a config valid on certain version will be still valid > even when it was migrated to a newer version and then back. Sorry, I've lost track of what the "This" is that would be necessary. > My current plan is to start qemu with -smp cpus=3D1,... and then call > query-hotpluggable-cpus and then hotplug all of them until the requested > configuration is satisfied. This approach is necessary so that we can > query for the model and topology info so that we don't need to > re-implement all the numbering and naming logic from qemu. Um.. why? What's the problem with just staring with -smp cpus=3Dwhatever and then using query-hotpluggable-cpus? > Additionally this will require us to mark one CPU as non-hotpluggable as > -smp cpus=3D0,maxcpus=3D10 is basically translated to -smp > cpus=3D10,maxcpus=3D10. The latter is true, but I'm not clear why it implies the former. --=20 David Gibson Senior Software Engineer, Virtualization, Red Hat --Sig_/X287O8vUP25H2QFxCg/.Vbw Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXbNmVAAoJEGw4ysog2bOSBN4QAICKBTIKCSJtXhhZSGXOQRUZ dqzZjkxRfZBn9XR7qeJ4a5YVOw6T4i6npSIM8SstBql7KGkrTf1G3dG8sehvzb0l NNziQ88/tLRqAoA+/38g16DWWMG2Znd211MiZ8xkebYoVFtHru8GE8h7MFoFS/NM /XN20cUC8TN/ImjchH+6K7rEqNahGZIJcEhjgaqLlVbmRHphohiq47tfJrqtXQwq 82VS/VlqH+u1zUldm7FauPQVowFmPDB3DTScI4Z1BHizxzTR5hijRmXD6/2g/2qm UYh+hbkcCwkU7lD1hcedJ7BrEdZYKsC8MMAnMFYILyjTmGbFw5/TXt+JXVH+cWao rMpifr4hI8iwfi5Hz6o2XrsnlHTeGIRU/xumu/0/i28eoCVxUjxx9rMJHHiszM3n Z+4xYO4BM60hsKhigmVUJe1Ojsymdn58yErahXDLLWD7VvdqT2pNQAR702T5FKVO sHtwcPrLAv3anooEoAacIJB3Xxj9d39ahltHK1u9Xn2Y5QySZved78kqSk0Esz+o /F3bsh0dGTBtY3QPlZUw5azq5sfQDD1TYtK1pKw4VcIRNsKAg1cfcDvobZAaGva3 TztxTtLbGJfcf595fXBKIoh3ZX6HswZne/ojJBFDeV5hLr7M/kUhe7hh3TKsFyvW 9cJtEhEyXbyprr1JJiBb =YGee -----END PGP SIGNATURE----- --Sig_/X287O8vUP25H2QFxCg/.Vbw--