<snip>
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
