From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHMRR-00076k-MI for qemu-devel@nongnu.org; Sun, 26 Jun 2016 22:38:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHMRN-00059v-Fu for qemu-devel@nongnu.org; Sun, 26 Jun 2016 22:38:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39037) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHMRN-00059U-7b for qemu-devel@nongnu.org; Sun, 26 Jun 2016 22:38:25 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 107AA3710D1 for ; Mon, 27 Jun 2016 02:38:24 +0000 (UTC) Date: Mon, 27 Jun 2016 12:40:04 +1000 From: David Gibson Message-ID: <20160627124004.0db53afe@voom.fritz.box> In-Reply-To: <20160624072118.GV3218079@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> <20160624165621.243d89d0@voom.fritz.box> <20160624072118.GV3218079@andariel.pipo.sk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/CMO1mbG53735iN+hGrRAFkC"; 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_/CMO1mbG53735iN+hGrRAFkC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 24 Jun 2016 09:21:18 +0200 Peter Krempa wrote: > On Fri, Jun 24, 2016 at 16:56:21 +1000, David Gibson wrote: > > On Fri, 24 Jun 2016 07:41:11 +0200 > > Peter Krempa wrote: > > =20 > > > On Fri, Jun 24, 2016 at 14:56:51 +1000, David Gibson wrote: > > >=20 > > > [...] > > > =20 > > > > > You are correct - query-commands says whether 'query-hotpluggable= -cpus' > > > > > exists as a command. But that is insufficient. See my review, o= r 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 hotplugg= ed. 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 com= mand. =20 > > > >=20 > > > > Ah, right. Or to put it another way, the availability of > > > > query-hotpluggable-cpus is global across qemu, whereas actually bei= ng > > > > 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 resu= lt > > > in termination of the VM. =20 > >=20 > > Oh.. I wasn't expecting the feature would be enabled at user request - > > I thought libvirt would just use it if available. =20 >=20 > Hmm, I think that will be possible to use the feature all the time after > all. I'll need to add multiple states for that though to track it in > the XML so that we can re-create it on migration the right way. Hmm... At least on Power, our intention is that just the machine type version determines which approach is in use. WIth machine type <=3D 2.6, the old style initialization will be used and hotplug will not be available. With machine type >=3D 2.7, new style will be used, and hotplug will be theoretically available, whether or not you actually use it and regardless of anything else on the command line. So I'm not really understanding why you need to track anything extra for migration here. > > > It is necessary though to report the availability of the feature to t= he > > > user via our domain capabilities API which some higher layer manageme= nt > > > apps use to make decisions. =20 > >=20 > > Right... what advantage does adding the machine flag have over > > attempting the query-hotpluggable-cpus? =20 >=20 > Mostly the ability for oVirt or open stack being able to query whether > it's available for given machine type prior to even attempting to launch > the VM. Otherwise the'll be left to either guessing or re-implementing > the support matrix. >=20 > This means that the ability to query it with machine types is not > strictly necessary for implementing the feature in libvirt but a > very-nice-to-have thing to add to our capabilities queries. Ok, makes sense. I'll merge the patch. > > > 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. =20 > >=20 > > Sorry, I've lost track of what the "This" is that would be necessary. = =20 >=20 > Never mind on this point. If I design the XML a bit differently it will > be possible to use this this feature if present all the time. Some cpus > just won't be available for unplug. Ok, still not seeing what any of this has to do with unplug. > > > 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 reques= ted > > > 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. =20 > >=20 > > Um.. why? What's the problem with just staring with -smp cpus=3Dwhatev= er > > and then using query-hotpluggable-cpus? > > =20 > > > 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. =20 > >=20 > > The latter is true, but I'm not clear why it implies the former. =20 >=20 > It necessarily doesn't imply it. I originally wanted to have most cpus > unpluggable but thinking again it is not really necessary I just need to > adapt the interface design. Again, not seeing what prevents unplug here. You do realise that query-hotpluggable-cpus lists already plugged as well as can-be-plugged packages? And those already plugged packages (including ones constructed initially) can be unplugged..? --=20 David Gibson Senior Software Engineer, Virtualization, Red Hat --Sig_/CMO1mbG53735iN+hGrRAFkC Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXcJIEAAoJEGw4ysog2bOSnGQP/2N/08LiJtkzhAyIBffwoXCg 6UkktV9FXjBQdcvsnIeJN7Dev6s+9+rz0TVBLrPxvZLN86jkIBgxv9OZ45j+HSVz /ySexUheKUfmtAjUXN10nRGlji+PIVlJhg+W58fviBOfeBiVj9YJjJEL+DlxLz5x mb+Kf/kWYUOY8DL4DYdTYBy9QRMvgfAc8Z4C3/IA4ca+62QJDwxVkyHulfKk2aEf wz/Bj920zEVmxgWto8JQ7vpJUc33FaXqacJ3116gklizqjeBdmFLh7F7L+8hEsn1 FBsxI0JPzwDoyJ6iRryn3UC1VS4Pgcw6vTYZIk8Vq90VBRoVneM8Mc0i/l5ZrPdF jSVANOgNoAGaVGBwMJAZiWjZsRD7OaihfG8Su2GqQZ2//jGOfe2jOwpbQ5rQDnWa LDhjjucGVoJImdGXm4+TmNIgvFoZeVzOFmHw3LXH1lU7h7UgW7NL6JAuvi4T3oK1 wSP4TCv50Ns44ha2gs+gniuGkfgfeROKHLJRYRoAXF9xHOwXq2XqgUbkK8HdxEx1 3TX3dYFXmM0OEdfIsph35yFtU9C64WPlIT4TeB55XSq4PMSF4E9FIsyM6rpMsze0 orEVXCl/3evN9jq1yehYRClRT5XeJsMP3AwoBN/6unEVG+PCltH30tMMsLfGGVpA yhVERM/utK9FU5V8rCqk =HEBa -----END PGP SIGNATURE----- --Sig_/CMO1mbG53735iN+hGrRAFkC--