[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus |
Date: |
Wed, 24 Feb 2016 12:31:03 +0100 |
On Wed, 24 Feb 2016 09:53:33 +0100
Markus Armbruster <address@hidden> wrote:
> Igor Mammedov <address@hidden> writes:
>
> > On Mon, 22 Feb 2016 13:54:32 +1100
> > David Gibson <address@hidden> 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
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, (continued)
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Igor Mammedov, 2016/02/19
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, David Gibson, 2016/02/21
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Igor Mammedov, 2016/02/23
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Eduardo Habkost, 2016/02/23
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, David Gibson, 2016/02/23
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, David Gibson, 2016/02/23
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus, Markus Armbruster, 2016/02/24
- Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus,
Igor Mammedov <=