x86: Use ACPI/MP for num_cores detection
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 23 Jul 2015 08:47:32 +0000 (04:47 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Fri, 24 Jul 2015 07:05:13 +0000 (03:05 -0400)
commit443f444d5efba89382139ead4da5791c95d4fcd1
tree71522d1c6610b4b5c2f26520ccccc91b30781af6
parentc24ce675f57fa1d99167f0fb7679dd211a147748
x86: Use ACPI/MP for num_cores detection

Previously, we'd use whatever booted up to determine the num_cores.  But
we would not know how many cores there should have been, and which may
be responding to SIPIs still.

That info is in the ACPI/MP tables.  Now, we can detect if the wrong
number of cores come online, and if the right number booted, we can free
the trapoline without any guesswork.

A couple other things:

The volatile on num_cores was probably due to early versions of the boot
code where C code needed to worry that assembly code was concurrently
incrementing num_cores/num_cpus.  That doesn't seem to be needed for
x86_num_cores_booted, let alone num_cores.

The u32 vs int for num_cores might also be for old code, where I didn't
want the variable to be negative ever.  Or more likely it was a
scalability joke.  Now that it's an int, we just went from 4 billion to
2 billion cores!  Oh no!

Setting num_cores to 1 in entry64.S, while its value in .data was 0xee
was just crazy.
kern/arch/x86/entry64.S
kern/arch/x86/smp_boot.c
kern/arch/x86/smp_entry64.S
kern/arch/x86/trap.c
kern/include/smp.h