x86: fixes early core_id() calls
authorBarret Rhoden <brho@cs.berkeley.edu>
Wed, 17 Jul 2013 21:21:28 +0000 (14:21 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Fri, 19 Jul 2013 23:56:06 +0000 (16:56 -0700)
commitb5fda4d4fe62f33a905ef7af99e30c2af88b21f2
treeb785866bae887f87e06d7f30989997a03ca8fc5d
parent9227daac46ce201316e38c146d073343bd4ac256
x86: fixes early core_id() calls

Ever since we set up minimal paging in assembly, we were unable to access the
LAPIC (and therefore coreid) until the LAPIC was mapped in during vm_init().
This prevented the newer panic and warn from working, and totally killed
spinlock debugging.

Previously, we had a full "virtual" KERNBASE mapping (in 32 bit) with
segmentation.  I think those attempted accesses of the unmapped LAPIC were just
silentely returning 0, which is the 'right' answer at that stage of bootup.
Either way, now that paging is on, unmapped LAPIC accesses would page fault and
trigger a reboot since the IDT isn't set up yet either.

Any callers of core_id() that can happen before vm_init() need to use
core_id_early().  I'm not overly concerned about code reachable via the
monitor, since if you got there, it's by a panic and we should already be
working on that problem.  If this is too much of a burden, we can just put the
bool check in core_id(), and take that potential cache miss on every call.
kern/arch/riscv/arch.h
kern/arch/x86/apic.c
kern/arch/x86/apic.h
kern/arch/x86/arch.h
kern/arch/x86/pmap32.c
kern/arch/x86/pmap64.c
kern/src/atomic.c
kern/src/init.c
kern/src/monitor.c