On Wed, 3 Apr 2013 15:10:05 -0300
Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Wed, Apr 03, 2013 at 07:58:00PM +0200, Igor Mammedov wrote:
> <snip>
> > > > +void do_cpu_hot_add(const int64_t id, Error **errp)
> > > > +{
> > > > + pc_new_cpu(saved_cpu_model, id, errp);
> > > > +}
> > > > +
> > >
> > > Missing x86_cpu_apic_id_from_index(id)?
> > There was(is?) opposition to using cpu_index to identify x86 CPU.
>
> Really? Do you have a pointer to the discussion?
Here is what I could find in my mail box:
http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg02770.html
Jan could correct me if I'm wrong.
>
>
> > So, it is expected from management to provide APIC ID instead of cpu_index.
> > It could be useful to make hotplug to a specific NUMA node/cpu to work in
> > future.
> > Though interface of possible APIC IDs discovery is not part of this series.
>
> That's exactly the opposite of what I expect. The APIC ID is an internal
> implementation detail, and external tools must _not_ be required to deal
> with it and to calculate it.
>
> Communication with the BIOS, on the other hand, is entirely based on the
> APIC ID, and not CPU indexes. So QEMU needs to translate the CPU indexes
> (used to communicate with the outside world) to APIC IDs when talking to
> the BIOS.
cpu_index won't work nicely with hot-adding CPU to specific numa node though.
with APIC ID (mgmt might treat it as opaque) we could expose something like
/machine/icc-bridge/link<CPU[apic_id_n]
...
for all possible CPUs, with empty links for non existing ones.
and later add on something like this:
/machine/numa_node[x]/link<CPU[apic_id_n]>
...
Libvirt than could just pickup ready apic id from desired place and add CPU
either using cpu-add id=xxx or device_add x86-cpu-...,apic_id=xxx
+1 more cpu_index is QEMU implementation detail and we could not add to x86 CPU
cpu-index property since hardware doesn't have such feature, so it won't be
available with device_add.
>
> --
> Eduardo
>
--
Regards,
Igor
