From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8iBc-0005oc-OQ for qemu-devel@nongnu.org; Tue, 15 Dec 2015 00:30:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8iBZ-0007bC-Jx for qemu-devel@nongnu.org; Tue, 15 Dec 2015 00:30:08 -0500 Received: from [59.151.112.132] (port=27385 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8iBZ-0007X4-9O for qemu-devel@nongnu.org; Tue, 15 Dec 2015 00:30:05 -0500 Message-ID: <566FA4BF.6080709@cn.fujitsu.com> Date: Tue, 15 Dec 2015 13:27:27 +0800 From: Zhu Guihua MIME-Version: 1.0 References: <1449728144-6223-1-git-send-email-bharata@linux.vnet.ibm.com> <20151210133505.22b303c7@igors-macbook-pro.local> <20151211035621.GC18759@in.ibm.com> In-Reply-To: <20151211035621.GC18759@in.ibm.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit 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: bharata@linux.vnet.ibm.com, Igor Mammedov Cc: mjrosato@linux.vnet.ibm.com, peter.maydell@linaro.org, ehabkost@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, borntraeger@de.ibm.com, izumi.taku@jp.fujitsu.com, pbonzini@redhat.com, afaerber@suse.de, david@gibson.dropbear.id.au >> 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 here, >> >> 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 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 ? > > 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 ? Is operating on core level not final decision ? For progress, I also agree to implement device_add for different archs. Thanks, Zhu