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 14:10:24 +0100

On Wed, 24 Feb 2016 22:26:04 +1100
David Gibson <address@hidden> wrote:

> On Thu, Feb 18, 2016 at 11:55:16AM +0100, Igor Mammedov wrote:
> > On Thu, 18 Feb 2016 15:05:10 +1100
> > David Gibson <address@hidden> wrote:
> >   
> > > On Tue, Feb 16, 2016 at 11:52:42AM +0100, Igor Mammedov wrote:  
> > > > On Tue, 16 Feb 2016 16:48:34 +1100
> > > > David Gibson <address@hidden> wrote:
> > > >     
> > > > > On Mon, Feb 15, 2016 at 08:43:41PM +0100, Markus Armbruster wrote:    
> > > > > > Igor Mammedov <address@hidden> writes:
> > > > > >       
> > > > > > > it will allow mgmt to query present and possible to hotplug CPUs
> > > > > > > it is required from a target platform that wish to support
> > > > > > > command to set board specific MachineClass.possible_cpus() hook,
> > > > > > > which will return a list of possible CPUs with options
> > > > > > > that would be needed for hotplugging possible CPUs.
> > > > > > >
> > > > > > > For RFC there are:
> > > > > > >    'arch_id': 'int' - mandatory unique CPU number,
> > > > > > >                       for x86 it's APIC ID for ARM it's MPIDR
> > > > > > >    'type': 'str' - CPU object type for usage with device_add
> > > > > > >
> > > > > > > and a set of optional fields that would allows mgmt tools
> > > > > > > to know at what granularity and where a new CPU could be
> > > > > > > hotplugged;
> > > > > > > [node],[socket],[core],[thread]
> > > > > > > Hopefully that should cover needs for CPU hotplug porposes for
> > > > > > > magor targets and we can extend structure in future adding
> > > > > > > more fields if it will be needed.
> > > > > > >
> > > > > > > also for present CPUs there is a 'cpu_link' field which
> > > > > > > would allow mgmt inspect whatever object/abstraction
> > > > > > > the target platform considers as CPU object.
> > > > > > >
> > > > > > > For RFC purposes implements only for x86 target so far.      
> > > > > > 
> > > > > > Adding ad hoc queries as we go won't scale.  Could this be solved 
> > > > > > by a
> > > > > > generic introspection interface?      
> > > > > 
> > > > > That's my main concern as well.
> > > > > 
> > > > > Igor,  did you see my post with a proposal for how to organize
> > > > > hotpluggable packages of CPUs?  I believe that would also solve the
> > > > > problem at hand here, by having a standard QOM location with
> > > > > discoverable cpu objects.
> > > > > 
> > > > > The interface in your patch in particular would *not* solve the
> > > > > problem of advertising to management layers what the granularity of
> > > > > CPU hotplug is, which we absolutely need for Power.    
> > > > I've had in mind Power as well, as topology items are optional
> > > > a query can respond with what granularity board would like
> > > > to use and what type of object it could be hotplugged:
> > > >     
> > > > -> { "execute": "query-hotpluggable-cpus" }    
> > > > <- {"return": [
> > > >      {"core": 2, "socket": 2, "arch_id": 2, "type": 
> > > > "power-foo-core-cpu"},
> > > >      {"core": 1, "socket": 1, "arch_id": 1, "type": 
> > > > "power-foo-core-cpu"},
> > > >      {"core": 0, "socket": 0, "arch_id": 0, "type": 
> > > > "power-foo-core-cpu", "cpu_link": "/machine/unattached/device[3]"}
> > > >    ]}    
> > > 
> > > Hrm.. except your arch_id is supplied by a CPUClass hook, making it a
> > > per-thread property, whereas here it needs to be per-core.  
> > That's only for demo purposes, it could be something else that is fixed
> > and stable. For example it could be QOM link path associated with it.
> > Like: { 'path': '/cpu[0]', ... }, or just something else to enumerate
> > a set of possible CPUs.  
> 
> Hm, ok.
> 
> > > Other than that I guess this covers what we need for Power, however I
> > > dislike the idea of typing the hotplug granularity to be at any fixed
> > > level of the socket/core/thread heirarchy.  As noted elsewhere, while
> > > all machines are likely to have some sort of similar heirarchy, giving
> > > it fixed levels of "socket", "core" and "thread" may be limiting.  
> > That's an optional granularity, if target doesn't care, it could skip
> > that parameters or even extend command to provide a target specific
> > parameters to create a CPU object, socket/core/thread are provided here
> > as they would fit majority usecases. These optional parameters are
> > basically a set of mandatory CPU object properties with values
> > that mgmt should supply at -device/device_add time to create a CPU with
> > expected properties.  
> 
> It seems really weird to me to tell management a bunch of parameters
> which it then needs to echo back to device_add.  If we're adding an
> interface, why not just add a "add/remove cpu unit" interface.
That would imply adding 3 interfaces:
  1 - to query, 2 - qmp/monitor to hot add/remove, 3 - CLI to describe 
configuration at startup

and to #2,3 one would have to echo back something(some id) that #1 had returned.

To avoid adding a least #2,3 CPUs were converted to Device and cpu feature 
flags to
object properties. So that it would be possible to reuse exiting
-device/device_add/device_del interface which is already supported by mgmt.



reply via email to

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