On Wed, 24 Feb 2016 09:53:33 +0100 Markus Armbruster <arm...@redhat.com> wrote:
> Igor Mammedov <imamm...@redhat.com> writes: > > > On Mon, 22 Feb 2016 13:54:32 +1100 > > David Gibson <da...@gibson.dropbear.id.au> wrote: > [...] > >> This is why Eduardo suggested - and I agreed - that it's probably > >> better to implement the "1st layer" as an internal structure/interface > >> only, and implement the 2nd layer on top of that. When/if we need to > >> we can revisit a user-accessible interface to the 1st layer. > > We are going around QOM based CPU introspecting interface for > > years now and that's exactly what 2nd layer is, just another > > implementation. I've just lost hope in this approach. > > > > What I'm suggesting in this RFC is to forget controversial > > QOM approach for now and use -device/device_add + QMP introspection, > > i.e. completely split interface from how boards internally implement > > CPU hotplug. > > QMP introspection doesn't tell you anything about device_add now. > Covering device_add is hard, because introspection data is fixed at > compile-time, but device models are collected only at run time. Worse, > non-qdev QOM properties are buried in code, which you have to run to > find them. See also my slide 39 of my KVM Form 2015 presentation > http://events.linuxfoundation.org/sites/events/files/slides/armbru-qemu-introspection.pdf > > But perhaps you means something else. It seems we are talking about different problems here. Goal of query-hotpluggable-cpus QMP command is not about -device cpu-foo introspection, but rather about providing a board specific runtime information about: - which CPU objects are present/possible and where - what[which CPU types] + with which properties values a new CPU[socket|core|thread] could be hotplugged For example query-hotpluggable-cpus could return: QEMU -cpu cpu_model_X -smp 2,threads=2,cores=3,maxcpus=6 -> { "execute": "query-hotpluggable-cpus" } <- {"return": [ {"core": 0, "type": "qemu64-power-core", "link" = "/machine/unattendended/device[X]"}, {"core": 1, "type": "qemu64-power-core"}, {"core": 2, "type": "qemu64-power-core"}, then to hotplug a CPU one could execute: device_add qemu64-power-core,core=2; then when it comes to migrating it's typical routine, target started like this: qemu-power -cpu cpu_model_X -smp 2,threads=2,cores=3,maxcpus=6 \ -device qemu64-power-core,core=2
