On Thu, Mar 05, 2015 at 04:47:53PM +0100, Andreas Färber wrote:
> Am 05.03.2015 um 14:37 schrieb Eduardo Habkost:
> > On Thu, Mar 05, 2015 at 01:32:02AM +0100, Andreas Färber wrote:
> >> Am 04.03.2015 um 03:13 schrieb Eduardo Habkost:
> >>> The APIC ID compatibility code is required only for PC, and now that
> >>> x86_cpu_initfn() doesn't use x86_cpu_apic_id_from_index() anymore, that
> >>> code can be moved to pc.c.
> >>>
> >>> Reviewed-by: Paolo Bonzini <pbonz...@redhat.com>
> >>> Reviewed-by: Andreas Färber <afaer...@suse.de>
> >>> Signed-off-by: Eduardo Habkost <ehabk...@redhat.com>
> >>> ---
> >>> hw/i386/pc.c | 35 +++++++++++++++++++++++++++++++++++
> >>> target-i386/cpu.c | 34 ----------------------------------
> >>> 2 files changed, 35 insertions(+), 34 deletions(-)
> >>>
> >>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> >>> index b229856..8c3c470 100644
> >>> --- a/hw/i386/pc.c
> >>> +++ b/hw/i386/pc.c
> [...]
> >>> @@ -629,6 +631,39 @@ bool e820_get_entry(int idx, uint32_t type, uint64_t
> >>> *address, uint64_t *length)
> >>> return false;
> >>> }
> >>>
> >>> +/* Enables contiguous-apic-ID mode, for compatibility */
> >>> +static bool compat_apic_id_mode;
> >>> +
> >>> +void enable_compat_apic_id_mode(void)
> >>> +{
> >>> + compat_apic_id_mode = true;
> >>> +}
> >>> +
> >>> +/* 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 x86_cpu_apic_id_from_index(unsigned int cpu_index)
> >>
> >> Looking a bit closer here, as I am poking around its call site for the
> >> socket modeling, can't this be made static while at it? (If so, don't
> >> forget to drop the prototype.)
> >
> > Yes, I'll make it static. I assume it's OK to do it before committing
> > instead of resending the series because of that?
>
> For me, sure. If you want to go safe or be verbose, you can post the
> diff as a reply when you apply.
Applied with fixup:
---
hw/i386/pc.c | 2 +-
target-i386/cpu.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 8c3c470..ed54d93 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -646,7 +646,7 @@ void enable_compat_apic_id_mode(void)
* 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 x86_cpu_apic_id_from_index(unsigned int cpu_index)
+static uint32_t x86_cpu_apic_id_from_index(unsigned int cpu_index)
{
uint32_t correct_id;
static bool warned;
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index 38bedc2..0638d24 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -1328,7 +1328,6 @@ void x86_cpu_compat_kvm_no_autodisable(FeatureWord w,
uint32_t features);
/* Return name of 32-bit register, from a R_* constant */
const char *get_register_name_32(unsigned int reg);
-uint32_t x86_cpu_apic_id_from_index(unsigned int cpu_index);
void enable_compat_apic_id_mode(void);
#define APIC_DEFAULT_ADDRESS 0xfee00000
--
2.1.0
--
Eduardo
