Re: [Qemu-devel] [PATCH 22/22] add cpu-add qmp command and implement CPU hot-add for target-i386

[Igor Mammedov]

On Tue, 9 Apr 2013 17:46:21 -0300
Eduardo Habkost <address@hidden> wrote:

> On Tue, Apr 09, 2013 at 10:19:11PM +0200, Igor Mammedov wrote:
> > On Fri, 5 Apr 2013 14:10:54 -0300
> > Eduardo Habkost <address@hidden> wrote:
> > 
> > > On Fri, Apr 05, 2013 at 04:37:16PM +0200, Igor Mammedov wrote:
> > > [...]
> > > > diff --git a/qapi-schema.json b/qapi-schema.json
> > > > index db542f6..a760ed5 100644
> > > > --- a/qapi-schema.json
> > > > +++ b/qapi-schema.json
> > > > @@ -1387,6 +1387,17 @@
> > > >  { 'command': 'cpu', 'data': {'index': 'int'} }
> > > >  
> > > >  ##
> > > > +# @cpu-add
> > > > +#
> > > > +# Adds CPU with specified id
> > > > +#
> > > > +# @id: cpu id of CPU to be created
> > > 
> > > Can we have the semantics/constraints of "id" documented here? Is it an
> > > arbitrary ID chosen by the caller? Does it have to be the APIC ID? Does
> > it's generic function so documenting it as APIC ID is not appropriate.
> > 
> > I for sure should document it on cpu-hotplug wiki page though, for x86 use
> > case for starters. i.e. how to use QMP to get a list of available/free IDs.
> > and in which order to use them.
> > 
> > > it have to be the index of the CPU in the CPU list? How the IDs of
> > > existing CPUs set using "-smp" are allocated?
> > With current -smp implementation the same way as it was before,
> > and for migration to work hot-plugged CPU has to be the next unused APIC
> > ID in their sequence, so that target qemu could be started with "-smp n+1".
> 
> The problem is that it's hard to find out what's the APIC ID for each
> CPU mentioned in the command-line.
> 
> For example, if you use "-smp 18,cores=3,threads=3,maxcpus=36" thread ID
> will use 2 bits, core ID will use 2 bits, the APIC IDs on startup will
> be:
> 
> online on startup:
> package 0, core 0: 0 1 2
> package 0, core 1: 4 5 6
> package 0, core 2: 8 9 10
> package 1, core 0: 16 17 18
> package 1, core 1: 20 21 22
> package 1, core 2: 24 25 26
> 
> offline on startup:
> package 2, core 0: 32 33 34
> package 2, core 1: 36 37 38
> package 2, core 2: 40 41 42
> package 3, core 0: 48 49 50
> package 3, core 1: 52 53 54
> package 3, core 2: 56 57 58
> 
> 
> What should the caller do to find out the correct ID for each of the 36
> VCPUs? This should be clearly documented.
Patch 21/22 exposes all APIC IDs (including offline) as links via QOM
as /machine/icc-bridge/cpu[0..n]
And since in above sequence IDs are monotonously increasing it's enough to use
the next unused APIC ID to make -smp n+1 work. 
> 
> 
> > 
> > But -smp along with -numa should be reworked to allow specifying guest 
> > visible
> > CPU IDs for arbitrary CPU hotplug to work.
> 
> I'm curious how you plan to make this work while keeping command-line
> compatibility. See the question I sent on my other message, about how to
> map the IDs used on -numa (that are "CPU indexes") to the IDs required
> by cpu-add.
It doesn't mean that we should stick to bad/insufficient interface forever. 
We could add new one that does it right and keep old one for a time being for
compatibility.

> 
> > 
> > when we done with QOMifying CPUs it might be possible to use -device for 
> > them
> > and keeping -smp for compat/shorcut purposes.
> > 
> > > 
> > > I am looking at the code right now to understand how this implementation
> > > works, but the documentation could contain or point to documentation on
> > > how the "id" parameter is used and interpreted.
> > I'll add pointer to wiki and describe there target-i386 use-case.
> 
> Thanks! Could you try to document it succintly inside qapi-schema.json
> as well? Maybe just a pointer to other documents would be useful.
It's very target specific, so separate document probably would make more sense.

> -- 
> Eduardo
> 


-- 
Regards,
  Igor