xv6-cs450/main.c

102 lines
2.4 KiB
C
Raw Normal View History

2006-06-12 17:22:12 +02:00
#include "types.h"
2007-08-28 01:26:33 +02:00
#include "defs.h"
2006-06-12 17:22:12 +02:00
#include "param.h"
#include "mmu.h"
#include "proc.h"
#include "x86.h"
2007-08-28 06:13:24 +02:00
static void bootothers(void);
2006-09-08 16:36:44 +02:00
// Bootstrap processor starts running C code here.
2007-08-28 01:32:16 +02:00
int
main(void)
2006-06-12 17:22:12 +02:00
{
int i;
2007-08-24 21:36:52 +02:00
static volatile int bcpu; // cannot be on stack
2007-08-28 06:13:24 +02:00
extern char edata[], end[];
2006-06-14 00:08:20 +02:00
// clear BSS
memset(edata, 0, end - edata);
kernel SMP interruptibility fixes. Last year, right before I sent xv6 to the printer, I changed the SETGATE calls so that interrupts would be disabled on entry to interrupt handlers, and I added the nlock++ / nlock-- in trap() so that interrupts would stay disabled while the hw handlers (but not the syscall handler) did their work. I did this because the kernel was otherwise causing Bochs to triple-fault in SMP mode, and time was short. Robert observed yesterday that something was keeping the SMP preemption user test from working. It turned out that when I simplified the lapic code I swapped the order of two register writes that I didn't realize were order dependent. I fixed that and then since I had everything paged in kept going and tried to figure out why you can't leave interrupts on during interrupt handlers. There are a few issues. First, there must be some way to keep interrupts from "stacking up" and overflowing the stack. Keeping interrupts off the whole time solves this problem -- even if the clock tick handler runs long enough that the next clock tick is waiting when it finishes, keeping interrupts off means that the handler runs all the way through the "iret" before the next handler begins. This is not really a problem unless you are putting too many prints in trap -- if the OS is doing its job right, the handlers should run quickly and not stack up. Second, if xv6 had page faults, then it would be important to keep interrupts disabled between the start of the interrupt and the time that cr2 was read, to avoid a scenario like: p1 page faults [cr2 set to faulting address] p1 starts executing trapasm.S clock interrupt, p1 preempted, p2 starts executing p2 page faults [cr2 set to another faulting address] p2 starts, finishes fault handler p1 rescheduled, reads cr2, sees wrong fault address Alternately p1 could be rescheduled on the other cpu, in which case it would still see the wrong cr2. That said, I think cr2 is the only interrupt state that isn't pushed onto the interrupt stack atomically at fault time, and xv6 doesn't care. (This isn't entirely hypothetical -- I debugged this problem on Plan 9.) Third, and this is the big one, it is not safe to call cpu() unless interrupts are disabled. If interrupts are enabled then there is no guarantee that, between the time cpu() looks up the cpu id and the time that it the result gets used, the process has not been rescheduled to the other cpu. For example, the very commonly-used expression curproc[cpu()] (aka the macro cp) can end up referring to the wrong proc: the code stores the result of cpu() in %eax, gets rescheduled to the other cpu at just the wrong instant, and then reads curproc[%eax]. We use curproc[cpu()] to get the current process a LOT. In that particular case, if we arranged for the current curproc entry to be addressed by %fs:0 and just use a different %fs on each CPU, then we could safely get at curproc even with interrupts disabled, since the read of %fs would be atomic with the read of %fs:0. Alternately, we could have a curproc() function that disables interrupts while computing curproc[cpu()]. I've done that last one. Even in the current kernel, with interrupts off on entry to trap, interrupts are enabled inside release if there are no locks held. Also, the scheduler's idle loop must be interruptible at times so that the clock and disk interrupts (which might make processes runnable) can be handled. In addition to the rampant use of curproc[cpu()], this little snippet from acquire is wrong on smp: if(cpus[cpu()].nlock == 0) cli(); cpus[cpu()].nlock++; because if interrupts are off then we might call cpu(), get rescheduled to a different cpu, look at cpus[oldcpu].nlock, and wrongly decide not to disable interrupts on the new cpu. The fix is to always call cli(). But this is wrong too: if(holding(lock)) panic("acquire"); cli(); cpus[cpu()].nlock++; because holding looks at cpu(). The fix is: cli(); if(holding(lock)) panic("acquire"); cpus[cpu()].nlock++; I've done that, and I changed cpu() to complain the first time it gets called with interrupts disabled. (It gets called too much to complain every time.) I added new functions splhi and spllo that are like acquire and release but without the locking: void splhi(void) { cli(); cpus[cpu()].nsplhi++; } void spllo(void) { if(--cpus[cpu()].nsplhi == 0) sti(); } and I've used those to protect other sections of code that refer to cpu() when interrupts would otherwise be disabled (basically just curproc and setupsegs). I also use them in acquire/release and got rid of nlock. I'm not thrilled with the names, but I think the concept -- a counted cli/sti -- is sound. Having them also replaces the nlock++/nlock-- in trap.c and main.c, which is nice. Final note: it's still not safe to enable interrupts in the middle of trap() between lapic_eoi and returning to user space. I don't understand why, but we get a fault on pop %es because 0x10 is a bad segment descriptor (!) and then the fault faults trying to go into a new interrupt because 0x8 is a bad segment descriptor too! Triple fault. I haven't debugged this yet.
2007-09-27 14:58:42 +02:00
// splhi() every processor during bootstrap.
2006-08-29 21:06:37 +02:00
for(i=0; i<NCPU; i++)
kernel SMP interruptibility fixes. Last year, right before I sent xv6 to the printer, I changed the SETGATE calls so that interrupts would be disabled on entry to interrupt handlers, and I added the nlock++ / nlock-- in trap() so that interrupts would stay disabled while the hw handlers (but not the syscall handler) did their work. I did this because the kernel was otherwise causing Bochs to triple-fault in SMP mode, and time was short. Robert observed yesterday that something was keeping the SMP preemption user test from working. It turned out that when I simplified the lapic code I swapped the order of two register writes that I didn't realize were order dependent. I fixed that and then since I had everything paged in kept going and tried to figure out why you can't leave interrupts on during interrupt handlers. There are a few issues. First, there must be some way to keep interrupts from "stacking up" and overflowing the stack. Keeping interrupts off the whole time solves this problem -- even if the clock tick handler runs long enough that the next clock tick is waiting when it finishes, keeping interrupts off means that the handler runs all the way through the "iret" before the next handler begins. This is not really a problem unless you are putting too many prints in trap -- if the OS is doing its job right, the handlers should run quickly and not stack up. Second, if xv6 had page faults, then it would be important to keep interrupts disabled between the start of the interrupt and the time that cr2 was read, to avoid a scenario like: p1 page faults [cr2 set to faulting address] p1 starts executing trapasm.S clock interrupt, p1 preempted, p2 starts executing p2 page faults [cr2 set to another faulting address] p2 starts, finishes fault handler p1 rescheduled, reads cr2, sees wrong fault address Alternately p1 could be rescheduled on the other cpu, in which case it would still see the wrong cr2. That said, I think cr2 is the only interrupt state that isn't pushed onto the interrupt stack atomically at fault time, and xv6 doesn't care. (This isn't entirely hypothetical -- I debugged this problem on Plan 9.) Third, and this is the big one, it is not safe to call cpu() unless interrupts are disabled. If interrupts are enabled then there is no guarantee that, between the time cpu() looks up the cpu id and the time that it the result gets used, the process has not been rescheduled to the other cpu. For example, the very commonly-used expression curproc[cpu()] (aka the macro cp) can end up referring to the wrong proc: the code stores the result of cpu() in %eax, gets rescheduled to the other cpu at just the wrong instant, and then reads curproc[%eax]. We use curproc[cpu()] to get the current process a LOT. In that particular case, if we arranged for the current curproc entry to be addressed by %fs:0 and just use a different %fs on each CPU, then we could safely get at curproc even with interrupts disabled, since the read of %fs would be atomic with the read of %fs:0. Alternately, we could have a curproc() function that disables interrupts while computing curproc[cpu()]. I've done that last one. Even in the current kernel, with interrupts off on entry to trap, interrupts are enabled inside release if there are no locks held. Also, the scheduler's idle loop must be interruptible at times so that the clock and disk interrupts (which might make processes runnable) can be handled. In addition to the rampant use of curproc[cpu()], this little snippet from acquire is wrong on smp: if(cpus[cpu()].nlock == 0) cli(); cpus[cpu()].nlock++; because if interrupts are off then we might call cpu(), get rescheduled to a different cpu, look at cpus[oldcpu].nlock, and wrongly decide not to disable interrupts on the new cpu. The fix is to always call cli(). But this is wrong too: if(holding(lock)) panic("acquire"); cli(); cpus[cpu()].nlock++; because holding looks at cpu(). The fix is: cli(); if(holding(lock)) panic("acquire"); cpus[cpu()].nlock++; I've done that, and I changed cpu() to complain the first time it gets called with interrupts disabled. (It gets called too much to complain every time.) I added new functions splhi and spllo that are like acquire and release but without the locking: void splhi(void) { cli(); cpus[cpu()].nsplhi++; } void spllo(void) { if(--cpus[cpu()].nsplhi == 0) sti(); } and I've used those to protect other sections of code that refer to cpu() when interrupts would otherwise be disabled (basically just curproc and setupsegs). I also use them in acquire/release and got rid of nlock. I'm not thrilled with the names, but I think the concept -- a counted cli/sti -- is sound. Having them also replaces the nlock++/nlock-- in trap.c and main.c, which is nice. Final note: it's still not safe to enable interrupts in the middle of trap() between lapic_eoi and returning to user space. I don't understand why, but we get a fault on pop %es because 0x10 is a bad segment descriptor (!) and then the fault faults trying to go into a new interrupt because 0x8 is a bad segment descriptor too! Triple fault. I haven't debugged this yet.
2007-09-27 14:58:42 +02:00
cpus[i].nsplhi = 1;
2006-07-12 19:00:54 +02:00
mp_init(); // collect info about this machine
bcpu = mp_bcpu();
2007-08-24 21:36:52 +02:00
// Switch to bootstrap processor's stack
asm volatile("movl %0, %%esp" : : "r" (cpus[bcpu].mpstack+MPSTACK-32));
asm volatile("movl %0, %%ebp" : : "r" (cpus[bcpu].mpstack+MPSTACK));
2006-07-12 19:00:54 +02:00
lapic_init(bcpu);
2007-08-28 01:26:33 +02:00
cprintf("\ncpu%d: starting xv6\n\n", cpu());
2006-06-12 17:22:12 +02:00
pinit(); // process table
binit(); // buffer cache
pic_init(); // interrupt controller
ioapic_init(); // another interrupt controller
kinit(); // physical memory allocator
tvinit(); // trap vectors
idtinit(); // interrupt descriptor table
fileinit(); // file table
iinit(); // inode cache
setupsegs(0); // segments & TSS
console_init(); // I/O devices & their interrupts
ide_init(); // disk
bootothers(); // boot other CPUs
if(!ismp)
2007-08-28 06:40:58 +02:00
timer_init(); // uniprocessor timer
kernel SMP interruptibility fixes. Last year, right before I sent xv6 to the printer, I changed the SETGATE calls so that interrupts would be disabled on entry to interrupt handlers, and I added the nlock++ / nlock-- in trap() so that interrupts would stay disabled while the hw handlers (but not the syscall handler) did their work. I did this because the kernel was otherwise causing Bochs to triple-fault in SMP mode, and time was short. Robert observed yesterday that something was keeping the SMP preemption user test from working. It turned out that when I simplified the lapic code I swapped the order of two register writes that I didn't realize were order dependent. I fixed that and then since I had everything paged in kept going and tried to figure out why you can't leave interrupts on during interrupt handlers. There are a few issues. First, there must be some way to keep interrupts from "stacking up" and overflowing the stack. Keeping interrupts off the whole time solves this problem -- even if the clock tick handler runs long enough that the next clock tick is waiting when it finishes, keeping interrupts off means that the handler runs all the way through the "iret" before the next handler begins. This is not really a problem unless you are putting too many prints in trap -- if the OS is doing its job right, the handlers should run quickly and not stack up. Second, if xv6 had page faults, then it would be important to keep interrupts disabled between the start of the interrupt and the time that cr2 was read, to avoid a scenario like: p1 page faults [cr2 set to faulting address] p1 starts executing trapasm.S clock interrupt, p1 preempted, p2 starts executing p2 page faults [cr2 set to another faulting address] p2 starts, finishes fault handler p1 rescheduled, reads cr2, sees wrong fault address Alternately p1 could be rescheduled on the other cpu, in which case it would still see the wrong cr2. That said, I think cr2 is the only interrupt state that isn't pushed onto the interrupt stack atomically at fault time, and xv6 doesn't care. (This isn't entirely hypothetical -- I debugged this problem on Plan 9.) Third, and this is the big one, it is not safe to call cpu() unless interrupts are disabled. If interrupts are enabled then there is no guarantee that, between the time cpu() looks up the cpu id and the time that it the result gets used, the process has not been rescheduled to the other cpu. For example, the very commonly-used expression curproc[cpu()] (aka the macro cp) can end up referring to the wrong proc: the code stores the result of cpu() in %eax, gets rescheduled to the other cpu at just the wrong instant, and then reads curproc[%eax]. We use curproc[cpu()] to get the current process a LOT. In that particular case, if we arranged for the current curproc entry to be addressed by %fs:0 and just use a different %fs on each CPU, then we could safely get at curproc even with interrupts disabled, since the read of %fs would be atomic with the read of %fs:0. Alternately, we could have a curproc() function that disables interrupts while computing curproc[cpu()]. I've done that last one. Even in the current kernel, with interrupts off on entry to trap, interrupts are enabled inside release if there are no locks held. Also, the scheduler's idle loop must be interruptible at times so that the clock and disk interrupts (which might make processes runnable) can be handled. In addition to the rampant use of curproc[cpu()], this little snippet from acquire is wrong on smp: if(cpus[cpu()].nlock == 0) cli(); cpus[cpu()].nlock++; because if interrupts are off then we might call cpu(), get rescheduled to a different cpu, look at cpus[oldcpu].nlock, and wrongly decide not to disable interrupts on the new cpu. The fix is to always call cli(). But this is wrong too: if(holding(lock)) panic("acquire"); cli(); cpus[cpu()].nlock++; because holding looks at cpu(). The fix is: cli(); if(holding(lock)) panic("acquire"); cpus[cpu()].nlock++; I've done that, and I changed cpu() to complain the first time it gets called with interrupts disabled. (It gets called too much to complain every time.) I added new functions splhi and spllo that are like acquire and release but without the locking: void splhi(void) { cli(); cpus[cpu()].nsplhi++; } void spllo(void) { if(--cpus[cpu()].nsplhi == 0) sti(); } and I've used those to protect other sections of code that refer to cpu() when interrupts would otherwise be disabled (basically just curproc and setupsegs). I also use them in acquire/release and got rid of nlock. I'm not thrilled with the names, but I think the concept -- a counted cli/sti -- is sound. Having them also replaces the nlock++/nlock-- in trap.c and main.c, which is nice. Final note: it's still not safe to enable interrupts in the middle of trap() between lapic_eoi and returning to user space. I don't understand why, but we get a fault on pop %es because 0x10 is a bad segment descriptor (!) and then the fault faults trying to go into a new interrupt because 0x8 is a bad segment descriptor too! Triple fault. I haven't debugged this yet.
2007-09-27 14:58:42 +02:00
cprintf("ismp %d\n", ismp);
cprintf("userinit\n");
userinit(); // first user process
// enable interrupts on this processor.
kernel SMP interruptibility fixes. Last year, right before I sent xv6 to the printer, I changed the SETGATE calls so that interrupts would be disabled on entry to interrupt handlers, and I added the nlock++ / nlock-- in trap() so that interrupts would stay disabled while the hw handlers (but not the syscall handler) did their work. I did this because the kernel was otherwise causing Bochs to triple-fault in SMP mode, and time was short. Robert observed yesterday that something was keeping the SMP preemption user test from working. It turned out that when I simplified the lapic code I swapped the order of two register writes that I didn't realize were order dependent. I fixed that and then since I had everything paged in kept going and tried to figure out why you can't leave interrupts on during interrupt handlers. There are a few issues. First, there must be some way to keep interrupts from "stacking up" and overflowing the stack. Keeping interrupts off the whole time solves this problem -- even if the clock tick handler runs long enough that the next clock tick is waiting when it finishes, keeping interrupts off means that the handler runs all the way through the "iret" before the next handler begins. This is not really a problem unless you are putting too many prints in trap -- if the OS is doing its job right, the handlers should run quickly and not stack up. Second, if xv6 had page faults, then it would be important to keep interrupts disabled between the start of the interrupt and the time that cr2 was read, to avoid a scenario like: p1 page faults [cr2 set to faulting address] p1 starts executing trapasm.S clock interrupt, p1 preempted, p2 starts executing p2 page faults [cr2 set to another faulting address] p2 starts, finishes fault handler p1 rescheduled, reads cr2, sees wrong fault address Alternately p1 could be rescheduled on the other cpu, in which case it would still see the wrong cr2. That said, I think cr2 is the only interrupt state that isn't pushed onto the interrupt stack atomically at fault time, and xv6 doesn't care. (This isn't entirely hypothetical -- I debugged this problem on Plan 9.) Third, and this is the big one, it is not safe to call cpu() unless interrupts are disabled. If interrupts are enabled then there is no guarantee that, between the time cpu() looks up the cpu id and the time that it the result gets used, the process has not been rescheduled to the other cpu. For example, the very commonly-used expression curproc[cpu()] (aka the macro cp) can end up referring to the wrong proc: the code stores the result of cpu() in %eax, gets rescheduled to the other cpu at just the wrong instant, and then reads curproc[%eax]. We use curproc[cpu()] to get the current process a LOT. In that particular case, if we arranged for the current curproc entry to be addressed by %fs:0 and just use a different %fs on each CPU, then we could safely get at curproc even with interrupts disabled, since the read of %fs would be atomic with the read of %fs:0. Alternately, we could have a curproc() function that disables interrupts while computing curproc[cpu()]. I've done that last one. Even in the current kernel, with interrupts off on entry to trap, interrupts are enabled inside release if there are no locks held. Also, the scheduler's idle loop must be interruptible at times so that the clock and disk interrupts (which might make processes runnable) can be handled. In addition to the rampant use of curproc[cpu()], this little snippet from acquire is wrong on smp: if(cpus[cpu()].nlock == 0) cli(); cpus[cpu()].nlock++; because if interrupts are off then we might call cpu(), get rescheduled to a different cpu, look at cpus[oldcpu].nlock, and wrongly decide not to disable interrupts on the new cpu. The fix is to always call cli(). But this is wrong too: if(holding(lock)) panic("acquire"); cli(); cpus[cpu()].nlock++; because holding looks at cpu(). The fix is: cli(); if(holding(lock)) panic("acquire"); cpus[cpu()].nlock++; I've done that, and I changed cpu() to complain the first time it gets called with interrupts disabled. (It gets called too much to complain every time.) I added new functions splhi and spllo that are like acquire and release but without the locking: void splhi(void) { cli(); cpus[cpu()].nsplhi++; } void spllo(void) { if(--cpus[cpu()].nsplhi == 0) sti(); } and I've used those to protect other sections of code that refer to cpu() when interrupts would otherwise be disabled (basically just curproc and setupsegs). I also use them in acquire/release and got rid of nlock. I'm not thrilled with the names, but I think the concept -- a counted cli/sti -- is sound. Having them also replaces the nlock++/nlock-- in trap.c and main.c, which is nice. Final note: it's still not safe to enable interrupts in the middle of trap() between lapic_eoi and returning to user space. I don't understand why, but we get a fault on pop %es because 0x10 is a bad segment descriptor (!) and then the fault faults trying to go into a new interrupt because 0x8 is a bad segment descriptor too! Triple fault. I haven't debugged this yet.
2007-09-27 14:58:42 +02:00
spllo();
2006-06-16 22:29:25 +02:00
kernel SMP interruptibility fixes. Last year, right before I sent xv6 to the printer, I changed the SETGATE calls so that interrupts would be disabled on entry to interrupt handlers, and I added the nlock++ / nlock-- in trap() so that interrupts would stay disabled while the hw handlers (but not the syscall handler) did their work. I did this because the kernel was otherwise causing Bochs to triple-fault in SMP mode, and time was short. Robert observed yesterday that something was keeping the SMP preemption user test from working. It turned out that when I simplified the lapic code I swapped the order of two register writes that I didn't realize were order dependent. I fixed that and then since I had everything paged in kept going and tried to figure out why you can't leave interrupts on during interrupt handlers. There are a few issues. First, there must be some way to keep interrupts from "stacking up" and overflowing the stack. Keeping interrupts off the whole time solves this problem -- even if the clock tick handler runs long enough that the next clock tick is waiting when it finishes, keeping interrupts off means that the handler runs all the way through the "iret" before the next handler begins. This is not really a problem unless you are putting too many prints in trap -- if the OS is doing its job right, the handlers should run quickly and not stack up. Second, if xv6 had page faults, then it would be important to keep interrupts disabled between the start of the interrupt and the time that cr2 was read, to avoid a scenario like: p1 page faults [cr2 set to faulting address] p1 starts executing trapasm.S clock interrupt, p1 preempted, p2 starts executing p2 page faults [cr2 set to another faulting address] p2 starts, finishes fault handler p1 rescheduled, reads cr2, sees wrong fault address Alternately p1 could be rescheduled on the other cpu, in which case it would still see the wrong cr2. That said, I think cr2 is the only interrupt state that isn't pushed onto the interrupt stack atomically at fault time, and xv6 doesn't care. (This isn't entirely hypothetical -- I debugged this problem on Plan 9.) Third, and this is the big one, it is not safe to call cpu() unless interrupts are disabled. If interrupts are enabled then there is no guarantee that, between the time cpu() looks up the cpu id and the time that it the result gets used, the process has not been rescheduled to the other cpu. For example, the very commonly-used expression curproc[cpu()] (aka the macro cp) can end up referring to the wrong proc: the code stores the result of cpu() in %eax, gets rescheduled to the other cpu at just the wrong instant, and then reads curproc[%eax]. We use curproc[cpu()] to get the current process a LOT. In that particular case, if we arranged for the current curproc entry to be addressed by %fs:0 and just use a different %fs on each CPU, then we could safely get at curproc even with interrupts disabled, since the read of %fs would be atomic with the read of %fs:0. Alternately, we could have a curproc() function that disables interrupts while computing curproc[cpu()]. I've done that last one. Even in the current kernel, with interrupts off on entry to trap, interrupts are enabled inside release if there are no locks held. Also, the scheduler's idle loop must be interruptible at times so that the clock and disk interrupts (which might make processes runnable) can be handled. In addition to the rampant use of curproc[cpu()], this little snippet from acquire is wrong on smp: if(cpus[cpu()].nlock == 0) cli(); cpus[cpu()].nlock++; because if interrupts are off then we might call cpu(), get rescheduled to a different cpu, look at cpus[oldcpu].nlock, and wrongly decide not to disable interrupts on the new cpu. The fix is to always call cli(). But this is wrong too: if(holding(lock)) panic("acquire"); cli(); cpus[cpu()].nlock++; because holding looks at cpu(). The fix is: cli(); if(holding(lock)) panic("acquire"); cpus[cpu()].nlock++; I've done that, and I changed cpu() to complain the first time it gets called with interrupts disabled. (It gets called too much to complain every time.) I added new functions splhi and spllo that are like acquire and release but without the locking: void splhi(void) { cli(); cpus[cpu()].nsplhi++; } void spllo(void) { if(--cpus[cpu()].nsplhi == 0) sti(); } and I've used those to protect other sections of code that refer to cpu() when interrupts would otherwise be disabled (basically just curproc and setupsegs). I also use them in acquire/release and got rid of nlock. I'm not thrilled with the names, but I think the concept -- a counted cli/sti -- is sound. Having them also replaces the nlock++/nlock-- in trap.c and main.c, which is nice. Final note: it's still not safe to enable interrupts in the middle of trap() between lapic_eoi and returning to user space. I don't understand why, but we get a fault on pop %es because 0x10 is a bad segment descriptor (!) and then the fault faults trying to go into a new interrupt because 0x8 is a bad segment descriptor too! Triple fault. I haven't debugged this yet.
2007-09-27 14:58:42 +02:00
cprintf("scheduler\n");
2006-07-11 03:07:40 +02:00
scheduler();
2006-06-12 17:22:12 +02:00
}
2006-06-22 22:47:23 +02:00
// Additional processors start here.
2007-08-28 20:23:48 +02:00
static void
mpmain(void)
{
2007-08-28 01:26:33 +02:00
cprintf("cpu%d: starting\n", cpu());
2007-08-24 21:36:52 +02:00
idtinit();
lapic_init(cpu());
setupsegs(0);
cpuid(0, 0, 0, 0, 0); // memory barrier
cpus[cpu()].booted = 1;
kernel SMP interruptibility fixes. Last year, right before I sent xv6 to the printer, I changed the SETGATE calls so that interrupts would be disabled on entry to interrupt handlers, and I added the nlock++ / nlock-- in trap() so that interrupts would stay disabled while the hw handlers (but not the syscall handler) did their work. I did this because the kernel was otherwise causing Bochs to triple-fault in SMP mode, and time was short. Robert observed yesterday that something was keeping the SMP preemption user test from working. It turned out that when I simplified the lapic code I swapped the order of two register writes that I didn't realize were order dependent. I fixed that and then since I had everything paged in kept going and tried to figure out why you can't leave interrupts on during interrupt handlers. There are a few issues. First, there must be some way to keep interrupts from "stacking up" and overflowing the stack. Keeping interrupts off the whole time solves this problem -- even if the clock tick handler runs long enough that the next clock tick is waiting when it finishes, keeping interrupts off means that the handler runs all the way through the "iret" before the next handler begins. This is not really a problem unless you are putting too many prints in trap -- if the OS is doing its job right, the handlers should run quickly and not stack up. Second, if xv6 had page faults, then it would be important to keep interrupts disabled between the start of the interrupt and the time that cr2 was read, to avoid a scenario like: p1 page faults [cr2 set to faulting address] p1 starts executing trapasm.S clock interrupt, p1 preempted, p2 starts executing p2 page faults [cr2 set to another faulting address] p2 starts, finishes fault handler p1 rescheduled, reads cr2, sees wrong fault address Alternately p1 could be rescheduled on the other cpu, in which case it would still see the wrong cr2. That said, I think cr2 is the only interrupt state that isn't pushed onto the interrupt stack atomically at fault time, and xv6 doesn't care. (This isn't entirely hypothetical -- I debugged this problem on Plan 9.) Third, and this is the big one, it is not safe to call cpu() unless interrupts are disabled. If interrupts are enabled then there is no guarantee that, between the time cpu() looks up the cpu id and the time that it the result gets used, the process has not been rescheduled to the other cpu. For example, the very commonly-used expression curproc[cpu()] (aka the macro cp) can end up referring to the wrong proc: the code stores the result of cpu() in %eax, gets rescheduled to the other cpu at just the wrong instant, and then reads curproc[%eax]. We use curproc[cpu()] to get the current process a LOT. In that particular case, if we arranged for the current curproc entry to be addressed by %fs:0 and just use a different %fs on each CPU, then we could safely get at curproc even with interrupts disabled, since the read of %fs would be atomic with the read of %fs:0. Alternately, we could have a curproc() function that disables interrupts while computing curproc[cpu()]. I've done that last one. Even in the current kernel, with interrupts off on entry to trap, interrupts are enabled inside release if there are no locks held. Also, the scheduler's idle loop must be interruptible at times so that the clock and disk interrupts (which might make processes runnable) can be handled. In addition to the rampant use of curproc[cpu()], this little snippet from acquire is wrong on smp: if(cpus[cpu()].nlock == 0) cli(); cpus[cpu()].nlock++; because if interrupts are off then we might call cpu(), get rescheduled to a different cpu, look at cpus[oldcpu].nlock, and wrongly decide not to disable interrupts on the new cpu. The fix is to always call cli(). But this is wrong too: if(holding(lock)) panic("acquire"); cli(); cpus[cpu()].nlock++; because holding looks at cpu(). The fix is: cli(); if(holding(lock)) panic("acquire"); cpus[cpu()].nlock++; I've done that, and I changed cpu() to complain the first time it gets called with interrupts disabled. (It gets called too much to complain every time.) I added new functions splhi and spllo that are like acquire and release but without the locking: void splhi(void) { cli(); cpus[cpu()].nsplhi++; } void spllo(void) { if(--cpus[cpu()].nsplhi == 0) sti(); } and I've used those to protect other sections of code that refer to cpu() when interrupts would otherwise be disabled (basically just curproc and setupsegs). I also use them in acquire/release and got rid of nlock. I'm not thrilled with the names, but I think the concept -- a counted cli/sti -- is sound. Having them also replaces the nlock++/nlock-- in trap.c and main.c, which is nice. Final note: it's still not safe to enable interrupts in the middle of trap() between lapic_eoi and returning to user space. I don't understand why, but we get a fault on pop %es because 0x10 is a bad segment descriptor (!) and then the fault faults trying to go into a new interrupt because 0x8 is a bad segment descriptor too! Triple fault. I haven't debugged this yet.
2007-09-27 14:58:42 +02:00
spllo();
scheduler();
}
2007-08-28 06:40:58 +02:00
static void
bootothers(void)
{
extern uchar _binary_bootother_start[], _binary_bootother_size[];
uchar *code;
struct cpu *c;
// Write bootstrap code to unused memory at 0x7000.
code = (uchar*)0x7000;
memmove(code, _binary_bootother_start, (uint)_binary_bootother_size);
for(c = cpus; c < cpus+ncpu; c++){
if(c == cpus+cpu()) // We've started already.
continue;
2007-08-28 06:13:24 +02:00
// Fill in %esp, %eip and start code on cpu.
*(void**)(code-4) = c->mpstack + MPSTACK;
*(void**)(code-8) = mpmain;
lapic_startap(c->apicid, (uint)code);
// Wait for cpu to get through bootstrap.
while(c->booted == 0)
;
}
}