From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9UiC-0001wG-F9 for qemu-devel@nongnu.org; Thu, 17 Dec 2015 04:19:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9Ui9-0007hk-4e for qemu-devel@nongnu.org; Thu, 17 Dec 2015 04:19:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Ui8-0007hg-TN for qemu-devel@nongnu.org; Thu, 17 Dec 2015 04:18:57 -0500 Date: Thu, 17 Dec 2015 10:19:07 +0100 From: Peter Krempa Message-ID: <20151217091907.GE1404639@andariel.pipo.sk> References: <1449728144-6223-1-git-send-email-bharata@linux.vnet.ibm.com> <20151210133505.22b303c7@igors-macbook-pro.local> <20151211035621.GC18759@in.ibm.com> <20151216161108.60825771@igors-macbook-pro.local> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Vwmj/TXzE7NEH899" Content-Disposition: inline In-Reply-To: <20151216161108.60825771@igors-macbook-pro.local> Subject: Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: mjrosato@linux.vnet.ibm.com, peter.maydell@linaro.org, zhugh.fnst@cn.fujitsu.com, ehabkost@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, borntraeger@de.ibm.com, Bharata B Rao , pbonzini@redhat.com, afaerber@suse.de, david@gibson.dropbear.id.au --Vwmj/TXzE7NEH899 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 16, 2015 at 16:11:08 +0100, Igor Mammedov wrote: > On Fri, 11 Dec 2015 09:27:57 +0530 > Bharata B Rao wrote: >=20 > > On Thu, Dec 10, 2015 at 01:35:05PM +0100, Igor Mammedov wrote: > > > On Thu, 10 Dec 2015 11:45:35 +0530 > > > Bharata B Rao wrote: [...] > > > For initial conversion of x86-cpus to device-add we could do pretty > > > much the same like we do now, where cpu devices will appear under: > > > /machine (pc-i440fx-2.5-machine) > > > /unattached (container) > > > /device[x] (qemu64-x86_64-cpu) > > >=20 > > > since we don't have to maintain/model dummy socket/core objects. > > >=20 > > > PowerPC could do the similar only at core level since it has > > > need for modeling core objects. > > >=20 > > > It doesn't change anything wrt current introspection state, since > > > cpus could be still found by mgmt tools that parse QOM tree. > > >=20 > > > We probably should split 2 conflicting goals we are trying to meet > > > here, > > >=20 > > > 1. make device-add/dell work with cpus / > > > drop support for cpu-add in favor of device_add=20 > > >=20 > > > 2. how to model QOM tree view for CPUs in arch independent manner > > > to make mgmt layer life easier. > > >=20 > > > and work on them independently instead of arguing for years, > > > that would allow us to make progress in #1 while still thinking > > > about how to do #2 the right way if we really need it. > >=20 > > Makes sense, s390 developer also recommends the same. Given that we > > have CPU hotplug patchsets from x86, PowerPC and s390 all > > implementing device_add semantics pending on the list, can we hope to > > get them merged for QEMU-2.6 ? > >=20 > > So as seen below, the device is either "cpu_model-cpu_type" or just > > "cpu_type". > generic device_add isn't able to deal with 'cpu_model' stuff, so > it should be concrete 'cpu_type'. > Question is if libvirt can get a list of supported CPU types.=20 >=20 > >=20 > > -device POWER8-powerpc64-cpu (pseries) > > -device qemu64-x86_64-cpu (pc) > > -device s390-cpu (s390) > >=20 > > Is this going to be the final acceptable semantics ? Would libvirt be > > able to work with this different CPU device names for different > > guests ? > CCing Peter to check if libvirt could do it nad if his is ok with > proposed device_add semantics as in the it's he who will deal with it > on libvirt side. Well, this depends entirely on the implementation and the variety of the cpu device models. Libvirt requires that the cpu model for a given arch/machine type/whatever can be inferred either completely offline or via monitor commands that are available when qemu is started with the 'none' machine type. This is required as we query capabilities of a qemu binary beforehand and then use the cached data to create the command line. Running a qemu process just to query a cpu model is not acceptable as it adds significant overhead. Peter --Vwmj/TXzE7NEH899 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWcn4LAAoJEDbsFqzQGGgrvBkP/j/vfdqo1UuXafzZcLKMkOnk ITDeEw++GA+vuLYR2en7o0zWJZEUXds/AGotgDSMSh+JDZ0KxOPU92N4wkWO2Brb aGpgM5Uz1JkY39N4T009iqvoc85LU2rqUzSRTVCxBhszd5jG/MLbkVnH79fACKAt /XSh93I8BYKaEe6E4unf6nESRE2rcoiFVzfq6nu90GwwJH/TrBkN1EiQZ6IKL9PY lw6zKZ1eNU6gGygfu6ExXH3hoKQX6XphVokCYFsuYAMLLshe8fYn+9vHqbGnCqVf DXeCjrTZLQG6t9BR3iyXjRaR7lHnDV2GKha6rBHLP8kU02JnSfOquDnqJdUCmz4i 0ketWW4iPuFRVA4uePsHNLjT4iff8HJgnTZYXKObFOmmSkuM8yhFjdV421zY3qjE 7sTj1uHckIfIJw6trNp1vma6s6RoDUdFe1IouPWi8UPcJw+vGsp+rpIz21wluwj3 9+FANTJEFasW9C6Hb8Snh8u9UIYYw+kHNHYaqtGyTOpAHiUbX3BL+JyZBUsMU8xk 4v7AScmw3olaAEei/Nx7eVJhAdCt+wkEqbIwQP8TLKPDRfHvCK6XJIcNluq0mase L1t+Wqp2zNBERxBA94i8RcXIcDV9tb9WTi8WWhERJN8P12XrA7cqWjgFH1gHcTR6 2ziGYtBzdbUrWGCbZhHV =UI+E -----END PGP SIGNATURE----- --Vwmj/TXzE7NEH899--