On Fri, 5 Apr 2013 14:10:54 -0300
Eduardo Habkost <ehabk...@redhat.com> 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".
But -smp along with -numa should be reworked to allow specifying guest visible
CPU IDs for arbitrary CPU hotplug to work.
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.
>
> > +#
> > +# Returns: Nothing on success
> > +##
> > +{ 'command': 'cpu-add', 'data': {'id': 'int'} }
> > +
> > +##
> --
> Eduardo
--
Regards,
Igor
