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 ?