\n\nThis page has been machine-translated from the original page.
\n
Inspired by Introduction to OS Code Reading ~Understanding the Kernel Mechanisms with UNIX V6, I’m reading xv6 OS.
\nSince UNIX V6 itself does not run on x86 CPUs, I’ve decided to read the source code of kash1064/xv6-public: xv6 OS, which is a fork of the xv6 OS repository that has adapted UNIXv6 to run on the X86 architecture.
\nPreviously, we read through the build and startup process of xv6 OS.
\nNow we’re going to proceed with reading the kernel.
\nFirst, let’s start reading from main.c.
Basically, we’ll read the C source code and trace the processing flow by performing gdb debugging while referencing kernel.asm and kernel.sym as needed.
In the previous article, we saw up to calling the main function in main.c.
From here, we’ll look at the behavior of the kernel itself.
\nFirst, I’ve extracted only the lines of the main function from main.c.
static void startothers(void);\nstatic void mpmain(void) __attribute__((noreturn));\nextern pde_t *kpgdir;\nextern char end[]; // first address after kernel loaded from ELF file\n\n// Bootstrap processor starts running C code here.\n// Allocate a real stack and switch to it, first\n// doing some setup required for memory allocator to work.\nint\nmain(void)\n{\n kinit1(end, P2V(4*1024*1024)); // phys page allocator\n kvmalloc(); // kernel page table\n mpinit(); // detect other processors\n lapicinit(); // interrupt controller\n seginit(); // segment descriptors\n picinit(); // disable pic\n ioapicinit(); // another interrupt controller\n consoleinit(); // console hardware\n uartinit(); // serial port\n pinit(); // process table\n tvinit(); // trap vectors\n binit(); // buffer cache\n fileinit(); // file table\n ideinit(); // disk \n startothers(); // start other processors\n kinit2(P2V(4*1024*1024), P2V(PHYSTOP)); // must come after startothers()\n userinit(); // first user process\n mpmain(); // finish this processor's setup\n}Functions are lined up and executed in order from top to bottom.
\nIn this article, we’ll look at the kinit1 and kinit2 functions.
The kinit1 function that is executed first is a function defined in kalloc.c.
The xv6 kernel initializes the memory allocator by calling kinit1 and kinit2.
// Initialization happens in two phases.\n// 1. main() calls kinit1() while still using entrypgdir to place just\n// the pages mapped by entrypgdir on free list.\n// 2. main() calls kinit2() with the rest of the physical pages\n// after installing a full page table that maps them on all cores.\nvoid\nkinit1(void *vstart, void *vend)\n{\n initlock(&kmem.lock, \"kmem\");\n kmem.use_lock = 0;\n freerange(vstart, vend);\n}\n\nvoid\nkinit2(void *vstart, void *vend)\n{\n freerange(vstart, vend);\n kmem.use_lock = 1;\n}At runtime, the kernel needs to allocate and free physical memory regions for page tables, processes, user memory, kernel stacks, pipe buffers, and so on.
\nIn the case of xv6 OS, the physical memory from the end of the address where the kernel itself is stored up to PHYSTOP is used as the allocation region.
PHYSTOP is defined in memlayout.h as follows:
#define EXTMEM 0x100000 // Start of extended memory\n#define PHYSTOP 0xE000000 // Top physical memory\n#define DEVSPACE 0xFE000000 // Other devices are at high addressesThe allocation and deallocation of this memory region is done on a page-by-page basis.
\nThe kernel maintains freed pages as a linked list, and when allocating, it removes that page from the list.
\nReference: xv6 - DRAFT as of September 4, 2018 P32-33
\nReference: Memory Management, Address Space, Page Tables
\nIn kinit1, the allocator is initialized to make the region from the kernel’s end address received as an argument up to 4MiB available “without locks”.
From here until the kinit2 function is called, it operates in a state where addresses from the kernel end to 4MiB can be allocated without locks.
This appears to be because most of the processing called within the main function cannot use locks or memory regions larger than 4MiB.
The kinit1 function is given vstart and vend as arguments.
First, the argument corresponding to the first argument vstart is the following variable declared in main.c.
It has an extern declaration and acquires PROVIDE(end = .); defined in kernel.ld.
extern char end[]; // first address after kernel loaded from ELF fileAlso, P2V(4*1024*1024) is given to vend.
P2V is a macro defined in memlayout.h that simply converts a physical address to a virtual address (= simply adds KERNBASE).
#define V2P(a) (((uint) (a)) - KERNBASE)\n#define P2V(a) ((void *)(((char *) (a)) + KERNBASE))When called, 0x80400000 is given, which is 4*1024*1024 (=4MiB) plus KERNBASE.
When I actually checked the arguments at the time of calling kinit1 with gdb, it looked like this:
kinit1 (vstart=0x801154a8, vend=0x80400000)The order is reversed, but in kinit1, these two values are given as arguments to the freerange function to secure the memory region.
Since I want to read the source code in order from the top, I’ll check the initlock function first.
The initlock function is a function defined in spinlock.c that initializes the spinlock structure inside the kmem structure.
The kmem structure is defined in kalloc.c as follows:
struct {\n struct spinlock lock;\n int use_lock;\n struct run *freelist;\n} kmem;Also, the spinlock structure is the following structure defined in spinlock.h.
The comment says mutual exclusion, and it seems to be used when performing locks.
\n// Mutual exclusion lock.\nstruct spinlock {\n uint locked; // Is the lock held?\n\n // For debugging:\n char *name; // Name of lock.\n struct cpu *cpu; // The cpu holding the lock.\n uint pcs[10]; // The call stack (an array of program counters)\n // that locked the lock.\n};The initlock function receives a pointer to this spinlock structure and a name string to initialize it.
void initlock(struct spinlock *lk, char *name)\n{\n lk->name = name;\n lk->locked = 0;\n lk->cpu = 0;\n}When calling this function from kinit1, we can see that it’s initialized with the name “kmem”.
void kinit1(void *vstart, void *vend)\n{\n initlock(&kmem.lock, \"kmem\");\n kmem.use_lock = 0;\n freerange(vstart, vend);\n}The next line also initializes the use_lock value to 0.
Here the lock is disabled.
\nIn kinit2, which is called after a while, kmem.use_lock is set to 1.
Also, here we’ve only initialized kmem and no lock has been performed.
To perform a lock using the structure initialized here, we need to call the void acquire(struct spinlock *lk) function defined in spinlock.c.
We’ll check this function when it’s actually used.
\nReference: Homework: xv6 locking
\nThe freerange function is a function defined in kalloc.c that takes vstart and vend as arguments and frees the physical address region aligned using PGROUNDUP.
void freerange(void *vstart, void *vend)\n{\n char *p;\n p = (char*)PGROUNDUP((uint)vstart);\n for(; p + PGSIZE <= (char*)vend; p += PGSIZE)\n kfree(p);\n}PGROUNDUP is defined in mmu.h as follows:
// Page directory and page table constants.\n#define NPDENTRIES 1024 // # directory entries per page directory\n#define NPTENTRIES 1024 // # PTEs per page table\n#define PGSIZE 4096 // bytes mapped by a page\n\n#define PTXSHIFT 12 // offset of PTX in a linear address\n#define PDXSHIFT 22 // offset of PDX in a linear address\n\n#define PGROUNDUP(sz) (((sz)+PGSIZE-1) & ~(PGSIZE-1))\n#define PGROUNDDOWN(a) (((a)) & ~(PGSIZE-1))PGROUNDUP is a macro that aligns the address received as an argument to a multiple of PGSIZE.
This returns the smallest multiple of PGSIZE greater than or equal to argument sz.
~ is the Bitwise NOT operator.
Also, (PGSIZE-1) is the maximum remainder for PGSIZE, so by adding this and then taking the AND with the bit-inverted (pgsize-1), we can round down the fraction below PGSIZE to perform alignment.
Reference: c - What do PGROUNDUP and PGROUNDDOWN in xv6 mean? - Stack Overflow
\nThe calculation was a bit difficult to understand, so I created a reversed Python script.
\ndef rev_PGROUNDUP(sz):\n print(\"***************rev_PGROUNDUP***************\")\n pgsize = 4096\n num1 = (sz)+(pgsize-1)\n num2 = ~(pgsize-1)\n result = num1 & num2\n print(\"pgsize : {}\".format(pgsize))\n print(\"pgsize[bin] : {}\".format(bin(pgsize)))\n print(\"(sz)+(pgsize-1) : {}\".format(num1))\n print(\"(sz)+(pgsize-1)[bin] : {}\".format(bin(num1)))\n print(\"~(pgsize-1) : {}\".format(num2))\n print(\"~(pgsize-1)[bin] : {}\".format(bin(num2)))\n print(\"result : {}\".format(result))\n print(\"result[bin] : {}\".format(bin(result)))\n return resultWhen this is executed, it looks like this:
\nrev_PGROUNDUP(100)\n***************rev_PGROUNDUP***************\npgsize : 4096\npgsize[bin] : 0b1000000000000\n(sz)+(pgsize-1) : 4195\n(sz)+(pgsize-1)[bin] : 0b1000001100011\n~(pgsize-1) : -4096\n~(pgsize-1)[bin] : -0b1000000000000\nresult : 4096\nresult[bin] : 0b1000000000000When 100 is input as sz, it’s aligned and rounded up, resulting in a return value of 4096.
Let’s go back to the freerange function.
vstart is given as the argument to PGROUNDUP, and the return value is stored in p.
void freerange(void *vstart, void *vend)\n{\n char *p;\n p = (char*)PGROUNDUP((uint)vstart);\n for(; p + PGSIZE <= (char*)vend; p += PGSIZE)\n kfree(p);\n}Here, p becomes an address aligned by PGSIZE.
From here until reaching the address of vend, physical addresses are freed by the kfree function every PGSIZE (every page), and the page list is initialized.
The kfree function frees memory and adds the freed page to the page list.
It’s defined in kalloc.c.
The starting address of the page to be freed is used as an argument.
\nWhen called from the kinit1 function, the value given as an argument is an address aligned by PGSIZE, so it’s guaranteed to be aligned on a 4096-byte boundary.
//PAGEBREAK: 21\n// Free the page of physical memory pointed at by v,\n// which normally should have been returned by a\n// call to kalloc(). (The exception is when\n// initializing the allocator; see kinit above.)\nvoid kfree(char *v)\n{\n struct run *r;\n\n if((uint)v % PGSIZE || v < end || V2P(v) >= PHYSTOP)\n panic(\"kfree\");\n\n // Fill with junk to catch dangling refs.\n memset(v, 1, PGSIZE);\n\n if(kmem.use_lock)\n acquire(&kmem.lock);\n r = (struct run*)v;\n r->next = kmem.freelist;\n kmem.freelist = r;\n if(kmem.use_lock)\n release(&kmem.lock);\n}When the function is called, it declares a run structure.
The run structure is defined in kalloc.c and is a singly-linked list that only has a reference to the next run structure.
It’s stored in kmem as a freelist that stores freed pages.
struct run {\n struct run *next;\n};\n\nstruct {\n struct spinlock lock;\n int use_lock;\n struct run *freelist;\n} kmem;The next line checks whether the address received as an argument is aligned by PGSIZE and that there is sufficient space for page size allocation.
If this check fails, the panic function is called.
if((uint)v % PGSIZE || v < end || V2P(v) >= PHYSTOP) panic(\"kfree\");The panic function will be described later.
The next line fills the address region for PGSIZE from the page start address v with 1.
// Fill with junk to catch dangling refs.\nmemset(v, 1, PGSIZE);memset will also be described later.
After the memory region initialization by memset is completed, the following lines are executed:
if(kmem.use_lock) acquire(&kmem.lock);\nr = (struct run*)v;\nr->next = kmem.freelist;\nkmem.freelist = r;\nif(kmem.use_lock) release(&kmem.lock);During the execution of kinit1, locks are disabled, so acquire and release are not called.
Therefore, a new run structure for one page is added to the head of kmem.freelist, and the processing of kfree ends.
This completes the processing of the freerange function, so the processing of kinit1 also ends, and we proceed to execute the next function in main.c.
After executing some kernel processing from kinit1, the kinit2 function is called.
The kinit2 function enables locks and secures a larger memory region.
The operation is almost the same as kinit1.
kinit2(P2V(4*1024*1024), P2V(PHYSTOP)); // must come after startothers()4MiB address is allocated to vstart, and 0xE000000, which is set as the end of the address region, is given to vend.
void kinit2(void *vstart, void *vend)\n{\n freerange(vstart, vend);\n kmem.use_lock = 1;\n}Except for the line kmem.use_lock = 1;, it’s the same as kinit1.
After freeing the region from vstart to vend with freerange and adding it to the page list, locks are enabled and it ends.
After this, since locks are enabled, the acquire and release functions will be called for memory allocation and deallocation.
Both the acquire and release functions are defined in spinlock.c.
Before reading the acquire and release functions, let’s check the lock specification in xv6.
xv6 OS operates in a multiprocessor environment.
\nIn a multiprocessor environment, multiple CPUs share physical memory resources.
\nTherefore, locks are a mechanism to prevent problems or conflicts caused by each CPU’s processing arbitrarily rewriting shared resources.
\nBy performing exclusive control of arbitrary memory regions through locks, we can make that memory region operable by only one CPU.
\nReference: xv6
\nIn xv6 OS, two types of locks are implemented: spin locks and sleep locks.
\nThe locks performed by the acquire and release functions are spin locks.
Reference: Spinlock - Wikipedia
\nWith spin locks, when a process tries to secure a memory resource, if the target is already locked, it loops and waits until the lock is released.
\nThe acquire function takes a pointer to a spinlock structure as an argument and performs a lock.
What we want to do here is simple: attempt to set 1 to locked in the spinlock structure, and loop the processing to wait until the lock can be secured.
// Acquire the lock.\n// Loops (spins) until the lock is acquired.\n// Holding a lock for a long time may cause\n// other CPUs to waste time spinning to acquire it.\nvoid acquire(struct spinlock *lk)\n{\n pushcli(); // disable interrupts to avoid deadlock.\n if(holding(lk))\n panic(\"acquire\");\n\n // The xchg is atomic.\n while(xchg(&lk->locked, 1) != 0);\n\n // Tell the C compiler and the processor to not move loads or stores\n // past this point, to ensure that the critical section's memory\n // references happen after the lock is acquired.\n __sync_synchronize();\n\n // Record info about lock acquisition for debugging.\n lk->cpu = mycpu();\n getcallerpcs(&lk, lk->pcs);\n}Let me also repost the definition of the spinlock structure.
// Mutual exclusion lock.\nstruct spinlock {\n uint locked; // Is the lock held?\n\n // For debugging:\n char *name; // Name of lock.\n struct cpu *cpu; // The cpu holding the lock.\n uint pcs[10]; // The call stack (an array of program counters)\n // that locked the lock.\n};Let’s look at the processing of the acquire function in order.
pushcli(); // disable interrupts to avoid deadlock.\nif(holding(lk)) panic(\"acquire\");The pushcli function is a function defined in spinlock.c.
Like cli, it suppresses interrupts, but here it implements nested interrupt disable instructions using a stack.
This processing prevents deadlocks that would occur if locks were held with interrupts enabled when securing locks with xchg later.
To resume interrupts, call the popcli function.
The popcli function is not called in the acquire function.
The popcli function corresponding to the pushcli function executed in the acquire function is executed by the release function.
// Pushcli/popcli are like cli/sti except that they are matched:\n// it takes two popcli to undo two pushcli. Also, if interrupts\n// are off, then pushcli, popcli leaves them off.\nvoid pushcli(void)\n{\n int eflags;\n\n eflags = readeflags();\n cli();\n if(mycpu()->ncli == 0) mycpu()->intena = eflags & FL_IF;\n mycpu()->ncli += 1;\n}\n\nvoid popcli(void)\n{\n if(readeflags()&FL_IF)\n panic(\"popcli - interruptible\");\n if(--mycpu()->ncli < 0)\n panic(\"popcli\");\n if(mycpu()->ncli == 0 && mycpu()->intena)\n sti();\n}The next holding function checks whether the CPU is locked.
// Check whether this cpu is holding the lock.\nint holding(struct spinlock *lock)\n{\n int r;\n pushcli();\n r = lock->locked && lock->cpu == mycpu();\n popcli();\n return r;\n}mycpu() is a function defined in proc.c.
xv6 OS manages a cpu structure for each CPU.
The cpu structure is defined in proc.h as follows, and various information is stored, such as the process currently executing on that CPU and the number of nested spin locks.
// Per-CPU state\nstruct cpu {\n uchar apicid; // Local APIC ID\n struct context *scheduler; // swtch() here to enter scheduler\n struct taskstate ts; // Used by x86 to find stack for interrupt\n struct segdesc gdt[NSEGS]; // x86 global descriptor table\n volatile uint started; // Has the CPU started?\n int ncli; // Depth of pushcli nesting.\n int intena; // Were interrupts enabled before pushcli?\n struct proc *proc; // The process running on this cpu or null\n};The mycpu function returns a pointer to reference the cpu structure of the current CPU.
Interrupts must be disabled before calling.
\nIn other words, if(holding(lk)) panic(\"acquire\"); references the spinlock structure in the argument and confirms that the CPU is locked.
Next, let’s check the lock setting.
\n// The xchg is atomic.\nwhile(xchg(&lk->locked, 1) != 0);Here, to prevent conflicts during lock operations, the operation needs to be atomic.
\nxchg is a special x86 instruction to achieve this.
If a lock is set, xchg(&lk->locked, 1) returns 1 and the loop continues.
If the lock is released, a new lock is set by xchg.
After that, the loop ends and the lock is secured.
\nReference: OSDev.org • View topic - How can xchg return a value?
\n// Tell the C compiler and the processor to not move loads or stores\n// past this point, to ensure that the critical section's memory\n// references happen after the lock is acquired.\n__sync_synchronize();\n\n// Record info about lock acquisition for debugging.\nlk->cpu = mycpu();\ngetcallerpcs(&lk, lk->pcs);Next, the __sync_synchronize function is a built-in function that performs a memory barrier.
Reference: c++ - What does _syncsynchronize do? - Stack Overflow
\nThen, the cpu structure acquired by the mycpu function is stored in lk->cpu.
Finally, the getcallerpcs function is called.
This stores the call stack for debugging.
\n// Record the current call stack in pcs[] by following the %ebp chain.\nvoid getcallerpcs(void *v, uint pcs[])\n{\n uint *ebp;\n int i;\n\n ebp = (uint*)v - 2;\n for(i = 0; i < 10; i++){\n if(ebp == 0 || ebp < (uint*)KERNBASE || ebp == (uint*)0xffffffff)\n break;\n pcs[i] = ebp[1]; // saved %eip\n ebp = (uint*)ebp[0]; // saved %ebp\n }\n for(; i < 10; i++)\n pcs[i] = 0;\n}It seems the information output when the panic function is called is stored here.
For the release function, there are no special points to note beyond what has been described so far, so I’ll omit the details.
// Release the lock.\nvoid release(struct spinlock *lk)\n{\n if(!holding(lk)) panic(\"release\");\n\n lk->pcs[0] = 0;\n lk->cpu = 0;\n\n // Tell the C compiler and the processor to not move loads or stores\n // past this point, to ensure that all the stores in the critical\n // section are visible to other cores before the lock is released.\n // Both the C compiler and the hardware may re-order loads and\n // stores; __sync_synchronize() tells them both not to.\n __sync_synchronize();\n\n // Release the lock, equivalent to lk->locked = 0.\n // This code can't use a C assignment, since it might\n // not be atomic. A real OS would use C atomics here.\n asm volatile(\"movl $0, %0\" : \"+m\" (lk->locked) : );\n\n popcli();\n}The last line asm volatile(\"movl $0, %0\" : \"+m\" (lk->locked) : ); sets 0 to locked and releases the lock.
The panic function is defined in console.c.
It seems to disable CPU interrupts and generate an infinite loop so that no further processing occurs.
\nvoid panic(char *s)\n{\n int i;\n uint pcs[10];\n\n cli();\n cons.locking = 0;\n // use lapiccpunum so that we can call panic from mycpu()\n cprintf(\"lapicid %d: panic: \", lapicid());\n cprintf(s);\n cprintf(\"\\n\");\n getcallerpcs(&s, pcs);\n for(i=0; i<10; i++)\n cprintf(\" %p\", pcs[i]);\n panicked = 1; // freeze other CPU\n for(;;)\n ;\n}To see what’s actually output, I decided to trigger a panic with gdb.
Execute the following commands in gdb in order:
\n# Connect to QEMU and set a breakpoint just before calling the panic function\n$ target remote localhost:26000\n$ b *0x80102499\n$ continue\n\n# Tamper with the flags register to call the panic function and execute\n$ info registers eflags\neflags 0x93 [ IOPL=0 SF AF CF ]\n$ set $CF = 0\n$ set $eflags ^= (1 << $CF)\n$ info registers eflags\neflags 0x92 [ IOPL=0 SF AF ]\n$ continueWhen I checked the QEMU console, I could see that panic was called when the kfree function was called.
The addresses displayed on the last line look like the return address stack.
\nReference: glibc/memset.c at master · lattera/glibc It seems to be implemented to operate faster than a simple for loop implementation. Reference: c++ - Memset Definition and use - Stack Overflow The xv6 Let’s actually check that memset is working using gdb. First, set a breakpoint just before executing Since we set a breakpoint, when I looked at the contents from the page start address for 0x1000 bytes, everything was 0. Next, when I looked at the same memory region just after We’ve finally progressed to the kernel itself. However, reading just the first function of the memset can write specific values to arbitrary address ranges at high speed, and is used for initialization, etc.memset is a much simpler implementation than the glibc one, but it seems to be implemented to operate faster than a for loop by using the stosb and stosl instructions.memset.$ target remote localhost:26000\n$ b memset\n$ continue# View the memory state just before executing memset\n$ x/1000 0x80116000\n0x80116000:0x000000000x000000000x000000000x00000000\n{ omitted }\n0x80116f90:0x000000000x000000000x000000000x00000000memset finished, I could confirm that all byte values were 1. (It’s hard to tell because the output is separated every 4 bytes.)# View the memory state just after executing memset\n$ finish\n$ $ x/1000 0x80116000\n0x80116000:0x010101010x010101010x010101010x01010101\n{ omitted }\n0x80116f90:0x010101010x010101010x010101010x01010101Summary
\nmain function has become quite voluminous, so I’ll compile the continuation in the next article.References
\n","fields":{"slug":"/unix-xv6-004-kernel-main-01-en","tagSlugs":["/tag/unix-en/","/tag/xv-6-en/","/tag/kernel-en/","/tag/os-en/","/tag/english/"]},"frontmatter":{"date":"2022-01-25","description":"Learning about the kernel by reading the source code of the educational OS xv6. This article explores the behavior of the main function in the xv6 OS kernel.","tags":["Unix (en)","xv6 (en)","Kernel (en)","OS (en)","English"],"title":"Reading xv6 OS in Depth to Completely Understand the Kernel - Memory Allocation and Mutual Exclusion -","socialImage":{"publicURL":"/static/9a7823be64a7e2f84c3e207689bb85a9/unix-xv6-004-kernel-main-01.png"}}}},"pageContext":{"slug":"/unix-xv6-004-kernel-main-01-en"}},"staticQueryHashes":["251939775","401334301","825871152"]}