x86: fixes lock debug issues with the new core_id
authorBarret Rhoden <brho@cs.berkeley.edu>
Tue, 17 Jun 2014 22:34:51 +0000 (15:34 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Tue, 17 Jun 2014 23:33:55 +0000 (16:33 -0700)
commit467b2adab632c9cffb7ee08621ede047f2111863
tree041502a81432e49c2e51f9b4937a59981d9ed6ce
parent1ee736ab0928a4b6ba9d760cbd33726a3a1d6ce8
x86: fixes lock debug issues with the new core_id

When spinlock debugging, we would do a core_id_early call and get gibberish
back.  This was because core_id_ready was set (it was being set once the LAPIC
was available, and not when the segmentation stuff was available).  Instead,
we'd get a garbage address and fault enough to reboot the machine.

The fix is to not start using core_id too early.

In doing so, we also expose an issue with the lock debugger being used.  The
older LAPIC styles were ready earlier than smp_boot (in vm_init()).  Now,
core_id isn't ready til the smp boot is mostly done.  In the meantime, the
non-zero cores will think they are core 0, which means all of them share a
pcpui->lock_depth.  Those cores are running concurrently, and the
pcpui->lock_depth isn't protected in any way.  Eventually, we'd screw up the
lock depth.  The fix there is to just not debug locks for a little while.
kern/arch/x86/apic.c
kern/arch/x86/apic.h
kern/arch/x86/coreid.h
kern/arch/x86/pmap32.c
kern/arch/x86/pmap64.c
kern/arch/x86/smp_boot.c
kern/src/kthread.c