summaryrefslogtreecommitdiff
path: root/proc.h
AgeCommit message (Collapse)AuthorFilesLines
2019-06-11separate source into kernel/ user/ mkfs/Robert Morris1-104/+0
2019-06-05spinlocks using gcc intrinsicsRobert Morris1-3/+2
push_off() / pop_off() set up per-hart plic stuff so all harts get device interrupts
2019-06-05start at support for multiple CPUsRobert Morris1-6/+2
2019-06-01first shell prints $ prompt, though no console input yetRobert Morris1-20/+35
2019-05-31fork/wait/exit workRobert Morris1-27/+57
2018-10-09Change mycpu() to use %gs.Frans Kaashoek1-0/+1
2018-10-09Separate system call path from trap path. Passes usertests on 1 and 2 cpus.Frans Kaashoek1-1/+1
2018-10-03use x86-64 namesFrans Kaashoek1-2/+2
2018-09-23Checkpoint port of xv6 to x86-64. Passed usertests on 2 processors a few times.Frans Kaashoek1-8/+13
The x86-64 doesn't just add two levels to page tables to support 64 bit addresses, but is a different processor. For example, calling conventions, system calls, and segmentation are different from 32-bit x86. Segmentation is basically gone, but gs/fs in combination with MSRs can be used to hold a per-core pointer. In general, x86-64 is more straightforward than 32-bit x86. The port uses code from sv6 and the xv6 "rsc-amd64" branch. A summary of the changes is as follows: - Booting: switch to grub instead of xv6's bootloader (pass -kernel to qemu), because xv6's boot loader doesn't understand 64bit ELF files. And, we don't care anymore about booting. - Makefile: use -m64 instead of -m32 flag for gcc, delete boot loader, xv6.img, bochs, and memfs. For now dont' use -O2, since usertests with -O2 is bigger than MAXFILE! - Update gdb.tmpl to be for i386 or x86-64 - Console/printf: use stdarg.h and treat 64-bit addresses different from ints (32-bit) - Update elfhdr to be 64 bit - entry.S/entryother.S: add code to switch to 64-bit mode: build a simple page table in 32-bit mode before switching to 64-bit mode, share code for entering boot processor and APs, and tweak boot gdt. The boot gdt is the gdt that the kernel proper also uses. (In 64-bit mode, the gdt/segmentation and task state mostly disappear.) - exec.c: fix passing argv (64-bit now instead of 32-bit). - initcode.c: use syscall instead of int. - kernel.ld: load kernel very high, in top terabyte. 64 bits is a lot of address space! - proc.c: initial return is through new syscall path instead of trapret. - proc.h: update struct cpu to have some scratch space since syscall saves less state than int, update struct context to reflect x86-64 calling conventions. - swtch: simplify for x86-64 calling conventions. - syscall: add fetcharg to handle x86-64 calling convetions (6 arguments are passed through registers), and fetchaddr to read a 64-bit value from user space. - sysfile: update to handle pointers from user space (e.g., sys_exec), which are 64 bits. - trap.c: no special trap vector for sys calls, because x86-64 has a different plan for system calls. - trapasm: one plan for syscalls and one plan for traps (interrupt and exceptions). On x86-64, the kernel is responsible for switching user/kernel stacks. To do, xv6 keeps some scratch space in the cpu structure, and uses MSR GS_KERN_BASE to point to the core's cpu structure (using swapgs). - types.h: add uint64, and change pde_t to uint64 - usertests: exit() when fork fails, which helped in tracking down one of the bugs in the switch from 32-bit to 64-bit - vectors: update to make them 64 bits - vm.c: use bootgdt in kernel too, program MSRs for syscalls and core-local state (for swapgs), walk 4 levels in walkpgdir, add DEVSPACETOP, use task segment to set kernel stack for interrupts (but simpler than in 32-bit mode), add an extra argument to freevm (size of user part of address space) to avoid checking all entries till KERNBASE (there are MANY TB before the top 1TB). - x86: update trapframe to have 64-bit entries, which is what the processor pushes on syscalls and traps. simplify lgdt and lidt, using struct desctr, which needs the gcc directives packed and aligned. TODO: - use int32 instead of int? - simplify curproc(). xv6 has per-cpu state again, but this time it must have it. - avoid repetition in walkpgdir - fix validateint() in usertests.c - fix bugs (e.g., observed one a case of entering kernel with invalid gs or proc
2017-02-01Eliminate code for gs trick to track per-cpu state. We rely on lapiccpunum()Frans Kaashoek1-29/+1
to find a per-cpu id with which we locate a cpu's cpu struct.
2017-01-31Read curproc from cpu structure, but be careful because after a schedule eventFrans Kaashoek1-0/+3
myproc() points to a different thread. myproc(); sched(); myproc(); // this proc maybe different than the one before sched Thus, in a function that operates on one thread better to retrieve the current process once at the start of the function.
2017-01-31Start of an experiment to remove the use of gs for cpu local variables.Frans Kaashoek1-8/+19
2016-09-02APIC IDs may not be consecutive and start from zero, so we cannot really use itFrans Kaashoek1-1/+1
as a direct index into cpus. Record apicid in struct cpu and have cpunum() look for it. Replace cpu->id with cpunum() everywhere, and replace cpu->id with cpu->apicid. Thanks to Xi Wang.
2016-08-25Remove trailing white space with:Frans Kaashoek1-1/+1
for f in *.{h,c}; do sed -i .sed 's/[[:blank:]]*$//' $f; done (Thanks to Nicolás Wolovick)
2016-08-10tiny clarifications to some gdt code.Robert Morris1-3/+0
2014-08-04use acquire/release to force order for pid=np->pid;np->state=RUNNINGRobert Morris1-1/+1
for bug reported by [email protected] and [email protected]
2012-08-28junkRobert Morris1-1/+1
2011-08-15Avoid "boot" in xv6Frans Kaashoek1-1/+1
2011-08-08One definition of several macros and constantsFrans Kaashoek1-7/+0
2010-09-13change some comments, maybe more informativeRobert Morris1-7/+7
delete most comments from bootother.S (since copy of bootasm.S) ksegment() -> seginit() move more stuff from main() to mainc()
2010-09-02Rearrange proc.h and proc.c to get our action-packed spreads back (mostly). ↵Austin Clements1-29/+30
They also make sense in this order, so it's not just for page layout.
2010-09-02Oops, missed a comment about the stack guardAustin Clements1-1/+0
2010-08-06fix corner cases in exec of ELFRobert Morris1-2/+3
put an invalid page below the stack have fork() handle invalid pages
2010-08-05add some commentsRobert Morris1-2/+2
find out the hard way why user and kernel must have separate segment descriptors
2010-07-02Initial version of single-cpu xv6 with page tablesFrans Kaashoek1-1/+1
2009-10-07fine-tune commentFrans Kaashoek1-2/+2
2009-10-07fine tune commentFrans Kaashoek1-1/+3
2009-09-02another attempt at cpu-local variables.Russ Cox1-8/+9
this time do it ourselves instead of piggybacking on TLS. add -fno-pic to Makefile; pic code breaks our fake TLS.
2009-09-02fix TLS again;Russ Cox1-1/+4
still not quite but a lot better.
2009-09-02Fix TLS for PIC systemsRuss Cox1-0/+1
2009-08-30assorted fixes:Russ Cox1-5/+5
* rename c/cp to cpu/proc * rename cpu.context to cpu.scheduler * fix some comments * formatting for printout
2009-05-31group locks into structs they protect.rsc1-2/+2
few naming nits.
2009-05-31tab policersc1-1/+1
2009-05-31Some proc cleanup, moving some of copyproc into allocproc.rsc1-15/+24
Also, an experiment: use "thread-local" storage for c and cp instead of the #define macro for curproc[cpu()].
2008-10-15indentkolya1-19/+19
2008-10-15cleaner swtch.Skolya1-15/+11
2007-10-01Incorporate new understanding of/with Intel SMP spec.rsc1-1/+1
Dropped cmpxchg in favor of xchg, to match lecture notes. Use xchg to release lock, for future protection and to keep gcc from acting clever.
2007-09-27Final word on the locking fiasco?rsc1-2/+2
Change pushcli / popcli so that they can never turn on interrupts unexpectedly. That is, if interrupts are on, then pushcli(); popcli(); turns them off and back on, but if they are off to begin with, then pushcli(); popcli(); is a no-op. I think our fundamental mistake was having a primitive (release and then popcli nee spllo) that could turn interrupts on at unexpected moments instead of being explicit about when we want to start allowing interrupts. With the new semantics, all the manual fiddling of ncli to force interrupts off in certain sections goes away. In return, we must explicitly mark the places where we want to enable interrupts unconditionally, by calling sti(). There is only one: inside the scheduler loop.
2007-09-27yank out stack overflow checking uglinessrsc1-4/+1
2007-09-27okay, that was long enough - revertrsc1-4/+1
2007-09-27test: store curproc at top of stackrsc1-1/+4
I don't actually think this is worthwhile, but I figured I would check it in before reverting it, so that it can be in the revision history. Pros: * curproc doesn't need to turn on/off interrupts * scheduler doesn't have to edit curproc anymore Cons: * it's ugly * all the stack computation is more complicated. * it doesn't actually simplify anything but curproc, and even curproc is harder to follow.
2007-09-27rename splhi/spllo to pushcli/popclirsc1-1/+1
2007-09-27overkill: use segments to catch stack overflow (delete before next year)rsc1-1/+4
2007-09-27use larger, allocated cpu stacksrsc1-3/+1
2007-09-27kernel SMP interruptibility fixes.rsc1-8/+6
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-08-28replace setjmp/longjmp with swtchrsc1-8/+8
2007-08-24Remove struct uinode.rsc1-1/+1
Remove type arg to mknod (assume T_DEV).
2007-08-24nitsrsc1-1/+1
2007-08-24add missing iput() at end of _namei()rtm1-8/+4
2007-08-23Use parent pointer instead of ppid.rsc1-1/+1