Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device

[Zhu Guihua <zhugh.fnst@cn.fujitsu.com>]

<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