From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9DpD-0006ug-Ah for qemu-devel@nongnu.org; Wed, 16 Dec 2015 10:17:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a9Dp9-0006qN-07 for qemu-devel@nongnu.org; Wed, 16 Dec 2015 10:17:07 -0500 Received: from mx2.suse.de ([195.135.220.15]:59451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a9Dp8-0006qJ-QB for qemu-devel@nongnu.org; Wed, 16 Dec 2015 10:17:02 -0500 References: <1449728144-6223-1-git-send-email-bharata@linux.vnet.ibm.com> <20151210133505.22b303c7@igors-macbook-pro.local> <20151211035621.GC18759@in.ibm.com> <566FA4BF.6080709@cn.fujitsu.com> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <5671806A.5040002@suse.de> Date: Wed, 16 Dec 2015 16:16:58 +0100 MIME-Version: 1.0 In-Reply-To: <566FA4BF.6080709@cn.fujitsu.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Zhu Guihua , bharata@linux.vnet.ibm.com, Igor Mammedov Cc: mjrosato@linux.vnet.ibm.com, peter.maydell@linaro.org, ehabkost@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, pbonzini@redhat.com, izumi.taku@jp.fujitsu.com, david@gibson.dropbear.id.au Am 15.12.2015 um 06:27 schrieb Zhu Guihua: > >>> and allow individual targets to use its own way to build CPUs? >>> >>> 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) >>> >>> since we don't have to maintain/model dummy socket/core objects. >>> >>> PowerPC could do the similar only at core level since it has >>> need for modeling core objects. >>> >>> It doesn't change anything wrt current introspection state, since >>> cpus could be still found by mgmt tools that parse QOM tree. >>> >>> We probably should split 2 conflicting goals we are trying to meet he= re, >>> >>> 1. make device-add/dell work with cpus / >>> drop support for cpu-add in favor of device_add >>> >>> 2. how to model QOM tree view for CPUs in arch independent manner >>> to make mgmt layer life easier. >>> >>> 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. >> Makes sense, s390 developer also recommends the same. Given that we ha= ve >> 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 ? >> >> So as seen below, the device is either "cpu_model-cpu_type" or just >> "cpu_type". >> >> -device POWER8-powerpc64-cpu (pseries) >> -device qemu64-x86_64-cpu (pc) >> -device s390-cpu (s390) >> >> Is this going to be the final acceptable semantics ? Would libvirt be >> able >> to work with this different CPU device names for different guests ? >=20 > Is operating on core level not final decision ? No, it is absolutely _not_ the conclusion from Seattle. Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N=FC= rnberg)