On Mon, Jan 21, 2013 at 12:18:55PM +0100, Andreas Färber wrote: > Am 17.01.2013 21:59, schrieb Eduardo Habkost: > > This function will be used by both the CPU initialization code and the > > fw_cfg table initialization code. > > > > Later this function will be updated to generate APIC IDs according to > > the CPU topology. > > > > Signed-off-by: Eduardo Habkost <ehabk...@redhat.com> > > --- > > target-i386/cpu.c | 17 ++++++++++++++++- > > target-i386/cpu.h | 2 ++ > > 2 files changed, 18 insertions(+), 1 deletion(-) > > > > diff --git a/target-i386/cpu.c b/target-i386/cpu.c > > index d1a14d5..d90789d 100644 > > --- a/target-i386/cpu.c > > +++ b/target-i386/cpu.c > > @@ -2194,6 +2194,21 @@ void x86_cpu_realize(Object *obj, Error **errp) > > cpu_reset(CPU(cpu)); > > } > > > > +/* Calculates initial APIC ID for a specific CPU index > > + * > > + * Currently we need to be able to calculate the APIC ID from the CPU index > > + * alone (without requiring a CPU object), as the QEMU<->Seabios > > interfaces have > > + * no concept of "CPU index", and the NUMA tables on fw_cfg need the APIC > > ID of > > + * all CPUs up to max_cpus. > > + */ > > +uint32_t apic_id_for_cpu(unsigned int cpu_index) > > Can we rather make this x86_cpu_apic_id(X86CPU *cpu) to account for > future changes to topology modelling?
We can't make it get a X86CPU as parameter, because the ACPI tables have to be built up to max_cpus, before the CPUs get actually created. But it can be renamed, yes. -- Eduardo
