qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]