pc: acpi: cpuhp-legacy: switch ProcessorID to possible_cpus idx
commit76bdd24ec05d9b8d41582a10602e6cf350541c6b
authorIgor Mammedov <imammedo@redhat.com>
Tue, 17 May 2016 14:43:03 +0000 (17 16:43 +0200)
committerMichael S. Tsirkin <mst@redhat.com>
Tue, 7 Jun 2016 12:36:54 +0000 (7 15:36 +0300)
tree53ff1b470081f9110ab70c82f51b5f21daf2a294
parentebd8ea82441020f2781928b17f37ed9a0d2e4250
pc: acpi: cpuhp-legacy: switch ProcessorID to possible_cpus idx

In legacy cpu-hotplug ProcessorID == APIC ID is used
in MADT and cpu-hotplug AML. It was fine as both
are 8bit and unique. Spec depricated Processor()
with corresponding ProcessorID and advises to use
Device() and UID instead of it.

However UID is just 32bit and it can't fit ARM's
arch_id(MPIDR) which is 64bit. Also in case of
sparse arch_id() distribution, managment/lookup
of maps by arch_id(APIC ID/MPIDR) becomes complex
and expensive.

In preparation to common CPU hotplug with ARM
and to simplify lookup in possible_cpus[] map
switch ProcessorID to possible_cpus index in
MADT.

Legacy cpu-hotplug considerations:
HW interface of it is APIC ID based bitmask so
it's impossible to change, also CPON package in
AML also APIC ID based as well all the methods.

To avoid massive rewrite of AML keep is so and
just break assumption that ProcessorID == APIC ID,
ammending CPU_MAT_METHOD to accept APIC ID and
possible_cpus index, it needs them both to patch
MADT entry template. Also switch to possible_cpus
index Processor(ProcessorID) AML.
That way changes to MADT/AML are minimal and kept
inside AML/MADT not affecting external interfaces.

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
hw/acpi/cpu_hotplug.c
hw/i386/acpi-build.c