Chen's Life

关于 AI 的一些思考

Sat, 07 Mar 2026 16:55:23 +0800

Chen's Life https://www.chens.life/posts/my-thinking-about-ai/ -

AI 时代，看来真的要来了。

三年前，也就是 2023 年，当 OpenAI 的 ChatGPT 问世，全世界都在惊叹 LLM 的拟人性的时候，我只当它是一个聊天工具或者查询工具。那时候我以为 AI 能摧毁的是搜索引擎，而不是 Coding 或者 Math。

三年后的今天，当各行各业都在使用 LLM 重新定义行业标准的时候，当全世界的大小团队都在推出自己的新模型和新技术或者新的理念的时候，我真正意识到未来可能真的要由 AI 来重新谱写了。

未来也许不是 LLM 的，但一定是属于 AI 的。也许 LLM 已经到达了发展的阈值，但 AI 前进的步伐不会停止，下一个技术爆炸的那一刻也许不会太远。

时代造就英雄，身处在这惊涛骇浪的中心，个人的学习和努力还剩下多少价值？

这个时代已经不再需要重复的低端劳动力和思考力，需要的是 AI 短时间内不会拥有的东西。

我认为在未来，个人的价值将体现在以下几个方面：

品味
逻辑
长期规划

品味

一个人的品味是独一无二的，就像一个人的审美那样五花八门。培养美的品味，更高级别的，富有创造力的品味，是 AI 无论如何在短时间内都不会拥有的东西。

培养欣赏美的直觉和能力，是一个人保持领先的关键因素，尤其在如今的 AI 时代中。

逻辑

LLM 不具备广泛意义上的逻辑能力。

逻辑就像互相连接的齿轮，也许未来随着 AI 技术的发展，AI 也会具有逻辑的能力，但逻辑能让我们知道什么是合理的，符合发展规律和事实规律的东西。

长期规格

当前 LLM 的局限性在于 context，它就相当于 LLM 的大脑容量。如果一个人拥有对事件信息的强大的处理和规划能力，那么他必然是超过 AI 一大截的。

这个一个技术平权，知识平权的时代。

LLM 的发展，极大的抹平了知识差距的鸿沟，让即使没受过教育的人也可以访问人类几千年积累的知识库。

这将更加凸显出那些极具品味，富有逻辑，并善于长期规划的人的价值所在，因为解决一个难题将不再是一个细节性问题，而是一个工程性问题。

工程学，逻辑学，心理学，美术和音乐，将是未来教育的重中之重，

- https://www.chens.life/posts/my-thinking-about-ai/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议

Rust 中两种 static 生命周期标注的区别

Sun, 01 Dec 2024 23:23:17 +0800

Chen's Life https://www.chens.life/posts/rust/differents-with-two-static-time-cycle/ -

Rust 中的 static 生命周期标注

Rust 中有的 static 生命周期意味着该类型的生命周期同整个程序的生命周期相同，意味着编译器会认为它一直是有效的。

在 Rust 中，有两种使用 static 生命周期标注的方法：

一种是类型本身的生命周期为 static: T: 'static.
另一种是，该类型指向的数据的生命周期为 static: T: &'static.

它们之间是有本质区别的。

T: ‘static

它表示规定 T 类型本身的生命周期是是 static 的。

use std::fmt::Display;

fn main() {
    static_bound("a static str"); // OK
}

// 'static 要求 T 类型的可以在 'static 生命周期内使用
fn static_bound<T: Display + 'static>(t: T) {
  println!("{}", t);
}

这是 OK 的，因为 static_bound 的参数要求生命周期必须为 static,而字符串字面值的生命周期正好符合。

但是下面的写法是错误的：

use std::fmt::Display;

fn main() {
    {
        let a_str = "a string".to_string();
        // 通过引用传递，生命周期依赖于 a_str 的作用域
        // 然而 a_str 的作用域不是整个程序(static)
        static_bound(&a_str); // OK
    }
}

// 'static 要求 T 类型的可以在 'static 生命周期内使用
fn static_bound<T: Display + 'static>(t: T) {
  println!("{}", t);
}

a_str 的生命周期不是 static，而 static_bound 要求 T 类型的生命周期必须为 static，所以编译报错，提示 a_str 存活的不够长。

T: ‘&static

我们将 static_bound 的参数列表改一下 (t: &T)，表示T的引用的内容的生命周期是 static,此时编译通过。

use std::fmt::Display;

fn main() {
    {
        let a_str = "a string".to_string();
        // 通过引用传递，生命周期依赖于 a_str 的作用域
        // 然后 a_str 的作用域不是整个程序(static)
        static_bound(&a_str); // OK
    }
}

// 'static 要求 T 类型的可以在 'static 生命周期内使用
fn static_bound<T: Display + 'static>(t: &T) {
  println!("{}", t);
}

这是因为 &'static 不管类型本身的生命周期，它只在乎引用所指向的内存中的数据是否在整个程序运行中存在。

那么 &a_str 指向一个字符串字面值，它一定在整个程序运行中存在，所以编译通过，它不在乎引用本身的作用域。

总结

通过上述例子可以看到:

T: 'static 在乎的是 T 类型本身的生命周期，也就是 T 类型本身的作用域;
T: &'static 在乎的是 T 类型指向的数据的作用域。

在一般代码实践中，应该避免使用 T: &'static ，因为这表明，即使 T 类型的作用域不是整个程序运行周期，编译器也会使其通过编译，就如第三个例子。

然而在遇到难以解决的生命周期的问题的时候，可以适当使用 T: 'static 使程序通过编译，使编译器理解我们的意思，不再阻拦我们。

- https://www.chens.life/posts/rust/differents-with-two-static-time-cycle/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议

写在2024

Sat, 02 Nov 2024 01:27:17 +0800

Chen's Life https://www.chens.life/posts/written-in-2024-11/ -

自大学毕业之后，终于是体会到了我原有所在阶级的生活，也进入到了所谓的“社会”中去。

时至今日，一年有余，回头再看，尽是波折和磨难。

都言行路难，如今我才知道这些话的分量，果然是难于上青天。

人生应该怎么度过，金钱可以决定，权力可以决定，人的意志也可以决定。很不幸的是，前两者占据了很大一部分的影响力。

当一个人从小小的校园中出发，带着行李在城市、农田和山林中穿梭的时候，我意识到，属于我的青春岁月就要结束了。

看不到尽头的重复的生活让我感觉疲惫不堪。

肉体和精神上的孤独尚且可以承受，看不到希望的无尽黑暗才是最让人绝望的事情。

小小的出租屋就像是一个坟墓，埋葬着我的理想和抱负。

极力的逃脱，我想逃离幽闭的出租屋，逃离让人失去激情的工位，逃离贫穷落后的家乡。

我明白，我真正想要的不是金钱，真正想要逃离的也不是这座城市。

我真正想要一种精神上的共鸣，它是模糊的，虚无的，飘渺的。

人总是看不清自己，不了解自己，追逐着资本家和政治家的无尽的陷阱，追逐着这个社会的既得利者的口号。

人总得知道自己真正想要什么。

2025年就要来了，时间如白驹过隙，流逝的飞快。

所有的失望和遗憾都将留在这里。

夕阳、海滩，赶海的人
2023.7 · 福州

- https://www.chens.life/posts/written-in-2024-11/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议

xv6-labs-2022 Lab6 Multithreading 答案与解析

Sun, 07 Apr 2024 23:56:33 +0800

Chen's Life https://www.chens.life/posts/mit-xv6-lab6/ -

本文不再像前文那样进行细致的翻译和讲解。

开始前，应该切换到 thread 分支，注意需要阅读 xv6-book 的 Chapter 7: Scheduling 章节。我建议先阅读，后面再来做lab，这样你会具有一个更加具体的概念。

Uthread: switching between threads

在这个练习中，你需要在用户级别的线程系统中设计一个上下文(context)切换机制。

xv6 提供了两个文件 user/uthread.c 和 user/uthread_switch.S，首先阅读这两个文件，尤其是 uthread.c，知道它是如何运行的。

你的任务：想出一个方法创建thread，并且在线程切换的时候保存和恢复CPU上下文。

思路

0x1

根据xv6-book，切换线程需要保存和恢复CPU上下文（也就是寄存器）的相关信息，所以在 struct thread 中，需要有CPU寄存器的相关信息，你手动添加它。我们不需要保存全部的寄存器，只需要保存 callee-save registers，你可以在 kernel/proc.h 中找到相关的内容，不过还是建议你阅读前面的超链接，你便你更好的了解。

所以在 user/uthread.c 中定义一个 struct context 来保存 callee-save registers 的信息。

struct context {
  uint64 ra; // return address
  uint64 sp; // stack pointer

  // callee-saved
  uint64 s0;
  uint64 s1;
  uint64 s2;
  uint64 s3;
  uint64 s4;
  uint64 s5;
  uint64 s6;
  uint64 s7;
  uint64 s8;
  uint64 s9;
  uint64 s10;
  uint64 s11;
};

struct thread {
  char       stack[STACK_SIZE]; /* the thread's stack */
  int        state;             /* FREE, RUNNING, RUNNABLE */
  struct context context;       // register context
};

0x2

user/uthread_switch.S 中，需要用asm编写保存和恢复寄存器的汇编代码，如果你做过前面的lab，或者认真读了xv6 book，那么这个函数 thread_switch(uint64, uint64) 和 kernel/swtch.S 中的swtch函数不能说一模一样，简直是没什么区别。

0x3

在 thread_schedule 中，很显然需要调用 thread_swtich 函数来保存寄存器和恢复CPU上下文为即将运行的进程的上下文信息。

xv6 book 中说道，thread switch 的原理就是通过保存原本的CPU上下文，然后恢复想要调度运行的进程的CPU上下文信息，其中最重要的就是寄存器 ra 的值，因为它保存着函数将要返回的地址 return address. 所以此时 ra 中的地址是什么，CPU就会跳转到这个地址进行运行。这就是所谓的 thread switch. 不过为了保持原本线程中的数据的完整性，需要一并恢复它所需要的寄存器的信息，也就是 callee-save resigers.

void 
thread_schedule(void)
{
  ...
  if (current_thread != next_thread) {         /* switch threads?  */
    ...
    /* YOUR CODE HERE
     * Invoke thread_switch to switch from t to next_thread:
     * thread_switch(??, ??);
     */
    // switch old to new thread
    // save old thread context and restore new thread context
    thread_switch(&t->context, &current_thread->context);
  } else
    next_thread = 0;
}

这里为了方便，我修改了 thread_switch 函数的参数原型：

extern void thread_switch(struct context *old, struct context *new);

0x4

通过上述0x3的讲解，你应该清楚了线程切换的根本原理。如何在一开始 thread_schedule 函数调度的时候，切换的新的CPU上下文信息中的 ra 寄存器为我们想要调转的那个函数的地址呢？答案就是在 thread_create 的时候，提前将对应的 thread 的 ra 寄存器设置为对应的函数地址。

同时需要注意，每个 thread 拥有一个独立的 stack 空间。所以需要同时将寄存器 sp (stack pointer) 设置为 thread.stack 的地址。

void 
thread_create(void (*func)())
{
  struct thread *t;

  for (t = all_thread; t < all_thread + MAX_THREAD; t++) {
    if (t->state == FREE) break;
  }
  t->state = RUNNABLE;
  // YOUR CODE HERE
  // save stack pointer to stack address
  t->context.sp = (uint64)&t->stack[0];
  t->context.ra = (uint64)(*func);
}

是不是挺有道理的？不过就是结果不正确，你会发现，经过一次两次 thread_switch 之后 thread[0\1\2..] 中的某些数据被修改为一个随机值了。比如 thread[0].state 在调度到 thread_a 之后，莫名的被修改为了一个随机的值，它正确的值应该为 1，因为它是 main 函数的线程，后面不会再进行调度。

其实原因就是 sp 的值错误了。学过操作系统原理的同学应该清楚，栈空间是从高往低填充的，也就是说 stack pointer 应该指向这个栈内存空间的高地址，而不是低地址。

在 C 语言中，一个数组的空间是从低地址向高地址分配的，所以此时 t->stack 是这个数组的低地址，我们需要将它的高地址传给 sp resiger. 也就是 &t->stack[STACK_SIZE-1];。所以正确的应该是：

  // save stack pointer to stack address
  t->context.sp = (uint64)&t->stack[STACK_SIZE-1];
  t->context.ra = (uint64)(*func);

我们应该掌握最基本的调式方法，详细的GDB调式方法见 https://sourceware.org/gdb/current/onlinedocs/gdb.html/

例如希望显示源代码 layout src ，希望显示asm代码 layout asm，二者都显示 layout split，见 https://sourceware.org/gdb/current/onlinedocs/gdb.html/TUI-Commands.html#TUI-Commands

在源代码中，如果执行 next 会执行多行asm代码，如果向单行调试asm代码，需要执行 si 。

详细的代码改动见 GitHub Commit.

Using threads

详见 GitHub commit，注意我的注释即可，最好画图分析一下指针，知道为什么会丢失数据。

static 
void put(int key, int value)
{
  int i = key % NBUCKET;

  // is the key already present?
  struct entry *e = 0;
  for (e = table[i]; e != 0; e = e->next) {
    if (e->key == key)
      break;
  }
  if(e){
    // update the existing key.
    e->value = value;
  } else {
  pthread_mutex_lock(&lock[i]);
    // the new is new.
    //  重要的是 table[i] 的值，如果 thread_1 刚进入，但是 thread_2 刚好完成修改了 table[i] 的操作，此时就会丢失后面的所有node
  insert(key, value, &table[i], table[i]);
  pthread_mutex_unlock(&lock[i]);
  }

}

Barrier

Barrier 是一种机制，可以让所有线程阻塞，直到所有线程都到达这个位置，然后继续运行。详见 Wikipedia.

pthread_cond_wait 在进入之后，会释放 mutex lock，返回之前会重新获取 mutex lock. 我们希望 bstate.nthread 记录阻塞的线程的数量仅在一个 thread 中递增一次，而不是多次增加。在所有线程到达之后，重置 bstate.nthread ，递增 bstate.round 表示一次回合。

首先我们需要使用 mutex lock 保护 bstate.nthread 的递增。因为如何不保护它，那么在多线程中会导致其结果最后不正确。如果其本来是 0，此时刚好计算到 bstate.nthread + 1 结束，结果是 1，但是还没有被赋值给 bstate.nthread，但是此时另一个线程刚好在此之前完成了对 bstate.nthread 的递增和赋值，此时 bstate.nthread = 1，然后回到刚才线程，执行赋值操作 bstate.nthread = 1 最终， bstate.nthread 的值为 1，显然是错误的，应该是 2.

static void 
barrier()
{
  pthread_mutex_lock(&bstate.barrier_mutex); // Lock the mutex

  // Increment the number of threads that have reached this round
  bstate.nthread++;

  // If not all threads have reached the barrier, wait
  if (bstate.nthread < nthread) {
      pthread_cond_wait(&bstate.barrier_cond, &bstate.barrier_mutex);
  }

  // If all threads have reached the barrier, increment the round and reset the counter
  if (bstate.nthread == nthread) {
      bstate.round++;
      bstate.nthread = 0;
      pthread_cond_broadcast(&bstate.barrier_cond); // Notify all waiting threads
  }

  pthread_mutex_unlock(&bstate.barrier_mutex); // Unlock the mutex
}

详细的代码改动见 GitHub Commit.

- https://www.chens.life/posts/mit-xv6-lab6/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议

xv6-labs-2022 Lab5 Copy on-write 答案与解析

Sat, 06 May 2023 16:53:28 +0800

Chen's Life https://www.chens.life/posts/mit-xv6-lab5-cow/ -

虚拟内存提供了一种间接性：内核可以将 PTE 标记为无效 (invalid) 或者只读 (read-only) 来阻止内存引用，并且导致页面故障 (page faults) 。在计算机系统中有一个说法，任何系统问题都能通过一定的间接性来解决。本次实验探索了一个例子：写时复制 (copy-on-write) fork.

开始之前切换到 cow 分支：

git fetch
git checkout cow
make clean

问题描述

xv6 中的 fork() 系统调用将父进程的所有用户空间内存都拷贝到子进程。如果父进程很大，那么这种拷贝将会花费很长时间。更糟糕的是，这经常会出现很大的浪费，因为 fork() 在子进程中，通常后面跟着 exec()，它通常使用已复制内存的很少一部分，这样就浪费了大量的内存空间。

解决方法

你的任务是实现写时复制 (copy-on-write) fork()，它可以推迟实际的物理内存的分配，直到真正使用要使用的时候，才会复制物理内存页。

COW fork() 仅仅为子进程创建了一个页表 (pagetable) ，页表中映射用户内存的 PTE 实际指向的是父进程的物理页。COW fork() 将父进程和子进程的用户 PTEs(user PTEs) 标记为只读 (read-only)。当任何一个进程试图向 COW 页写入操作的时候，CPU 将会引发一个页面错误 (page fault)。内核中的页面错误处理函数将会检测到这种情况，为发生错误的进程分配一个物理内存页，并把原始页（也就是父进程和子进程共享的物理页）中的数据复制到新分配的页中，然后修改故障进程中相关的 PTE ，使其指向新分配的物理页的地址，最后将此 PTE 标记为可写 (writeable)。错误页面处理函数完成任务之后，用户进程对于它的复制页将是可写的。

COW fork() 使得用户内存的物理页面的释放变得稍微有些复杂。一个给定的物理页有可能同时被多个进程所引用，这是因为由于 COW 的延迟分配机制，父进程和子进程共享同一个物理页所导致的。所以，我们应该在释放一个物理页的时候，确保该物理页没有一个进程在使用。在 xv6 这种简单内核中，我们的实现非常直接简单，仅仅使用一个数组来进行标记。但是在成熟内核中，这可能很难做到。

Implement copy-on-write fork(hard)

你的任务是在 xv6 内核中实现 copy-on-write fork 。如果运行 cowtest 和 usertests -q 都成功，那么这个实验就成功了。

为了帮助你测试你的代码，我们提供了一个 cowtest xv6 程序（源代码在 user/cowtest.c。它将会运行多个测试，在没有修改的 xv6 中，它将会在第一个测试中就失败。

$ cowtest
simple: fork() failed
$

这个 “simple” 测试会分配超过一半的可用物理内存，然后调用 fork() 。由于此时没有实现 COW fork() ，所以这里会因为没有足够的空闲内存空间而发生失败。

当你完成的时候，运行这两个测试程序，应该显示如下结果：

$ cowtest
simple: ok
simple: ok
three: zombie!
ok
three: zombie!
ok
three: zombie!
ok
file: ok
ALL COW TESTS PASSED
$ usertests -q
...
ALL TESTS PASSED
$

下面是一些建议：

修改 uvmcopy() ，将父进程的物理页映射到子进程，以避免分配新的页。同时清楚子进程和父进程 PTE 的 PTE_W 位，使它们标记为不可写。
修改 usertrap() ，以此来处理页面错误 (page fault)。当在一个本来可写的 COW 页发生“写页面错误” (write page-falut) 的时候，使用 kalloc() 分配一个新的页，将旧页中的数据拷贝到新页中，并将新页的 PTE 的 PTE_W 位置为1. 值得注意的是，对于哪些本来就使只读的（例如代码段），不论在旧页还是新页中，应该依旧保持它的只读性，那些试图对这样一个只读页进行写入的进程应该被杀死。
确保没有一个物理页被 PTE 引用之后，再释放它们，不能提前释放。一个好的做法是，维持一个“引用计数数组” (reference count) ，使用索引代表对应的物理页，值代表被引用的个数。当调用 kalloc() 分配一个物理页的时候，将其 reference count 设置为 1 。当 fork 导致子进程共享同一个页的时候，递增其页的引用计数；当任何一个进程从它们的页表中舍弃这个页的时候，递减其页的引用计数。kfree() 仅当一个页的引用计数为零时，才将这个页放到空闲页列表中。将这些引用计数放到一个 int 类型的数组中是可以的，你必须思考，如何去索引这个数组，以及如何选择这个数组的大小。例如，你可以用一个 页的物理地址/4096 来索引数组。
修改 copyout() ，使用类似的思路去处理 COW 页。

一些注意的点：

记录一个 PTE 是否是 COW 映射是有帮助的。你可以使用 RISC-V PTE 的 RSW (reserved for software) 位来指示。
usertests -q 测试一些 cowtest 没有测试的东西，所以不要忘记两个测试都要通过。
一些对于页表标志 (page table flags) 有用的宏和定义可以在 kernel/riscv.h 中找到。
如果一个 COW 页错误发生时，没有剩余可用内存，那么该进程应该被杀死。

思路

首先需要处理引用计数的问题。在 kernel/kalloc.c 中定义一个全局变量和锁。

// the reference count of physical memory page
int useReference[PHYSTOP/PGSIZE];
struct spinlock ref_count_lock;

然后在函数 kalloc() 中，初始化新分配的物理页的引用计数为 1.

void *
kalloc(void)
{
  ...
  if(r) {
    kmem.freelist = r->next;
    acquire(&ref_count_lock);
    // initialization the ref count to 1
    useReference[(uint64)r / PGSIZE] = 1;
    release(&ref_count_lock);
  }
  release(&kmem.lock);
  ...
}

接着修改 kfree() ，仅当引用计数小于等于 0 的时候，才回收对应的页。

void
kfree(void *pa)
{
  ...
  if(((uint64)pa % PGSIZE) != 0 || (char*)pa < end || (uint64)pa >= PHYSTOP)
    panic("kfree");

  acquire(&ref_count_lock);
  // decrease the reference count, if use reference is not zero, then return
  useReference[(uint64)pa/PGSIZE] -= 1;
  temp = useReference[(uint64)pa/PGSIZE];
  release(&ref_count_lock);
  if (temp > 0)
    return;

  // Fill with junk to catch dangling refs.
 ...
}

之所以不使用 if (temp != 0) ，因为在系统运行开始的时候，需要对空闲页列表 (kmem.freelist) 进行初始化，此时的引用计数就为 -1 ，如果条件为 temp != 0 那么这些空闲页就不能够回收，也就不能够 kmem.freelist 列表了。

fork 会首先调用 uvmcopy() 给子进程分配内存空间。但是如果要实现 COW 机制，就需要在 fork 时不分配内存空间，而是让子进程和父进程同时共享父进程的内存页，并将其设置为只读，使用 PTE_RSW 位标记 COW 页。这样子进程没有使用到某些页的时候，系统就不会真正的分配物理内存。注意，此时需要将对应的引用计数加一。

这里在修改 PTE_W 和 PTE_RSW 位的时候，需要考虑原本的页是否使可写的。如果原本的页是只读的，那么就不用将其修改为 COW 页，因为 COW 页会在 usertrap() 中重新分配内存，并赋予可写权限，这样就违背了其原来的意愿，导致安全问题。

只有原本的页是可写的，才将其标记为 COW 和只读。

首先在 kernel/riscv.h 中增加一些定义。

#define PTE_RSW (1L << 8) // RSW

然后修改 uvmcopy 函数。此函数在 vm.c 文件中，由于需要使用 useReference 引用计数，所以需要提前在文件开头声明。

#include "spinlock.h"
#include "proc.h"

// Just declare the variables from kernel/kalloc.c
extern int useReference[PHYSTOP/PGSIZE];
extern struct spinlock ref_count_lock;

int
uvmcopy(pagetable_t old, pagetable_t new, uint64 sz)
{
  ...
  // char *mem;
  for(i = 0; i < sz; i += PGSIZE){
    if((pte = walk(old, i, 0)) == 0)
      panic("uvmcopy: pte should exist");
    if((*pte & PTE_V) == 0)
      panic("uvmcopy: page not present");
    // PAY ATTENTION!!!
    // 只有父进程内存页是可写的，才会将子进程和父进程都设置为COW和只读的；否则，都是只读的，但是不标记为COW，因为本来就是只读的，不会进行写入
    // 如果不这样做，父进程内存只读的时候，标记为COW，那么经过缺页中断，程序就可以写入数据，于原本的不符合
    if (*pte & PTE_W) {
      // set PTE_W to 0
      *pte &= ~PTE_W;
      // set PTE_RSW to 1
      // set COW page
      *pte |= PTE_RSW;
    }
    pa = PTE2PA(*pte);

    // increment the ref count
    acquire(&ref_count_lock);
    useReference[pa/PGSIZE] += 1;
    release(&ref_count_lock);

    flags = PTE_FLAGS(*pte);
    // if((mem = kalloc()) == 0)
    //   goto err;
    // memmove(mem, (char*)pa, PGSIZE);
    if(mappages(new, i, PGSIZE, (uint64)pa, flags) != 0){
      // kfree(mem);
      goto err;
    }
  }
  ...
}

一旦子进程真正需要某些页，由于页被设置为只读的，此时会触发 Store/AMO page fault，scause 寄存器的值为 15。

在 usertrap() 函数中捕获到 Store/AMO page fault 错误之后开始处理。首先应该知道哪个虚拟地址的操作导致了页错误。RISC-V 中的 stval (Supervisor Trap Value (stval) Register ) 寄存器中的值是导致发生异常的虚拟地址。vx6 中的函数 r_stval() 可以获取该寄存器的值。

修改 usertrap 函数。

void
usertrap(void)
{
  ...
  syscall();
  }
  else if (r_scause() == 15) {
    // Store/AMO page fault(write page fault)
    // see Volume II: RISC-V Privileged Architectures V20211203 Page 71

    // the faulting virtual address
    // see Volume II: RISC-V Privileged Architectures V20211203 Page 70
    // the download url is https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf
    uint64 va = r_stval();
    if (va >= p->sz)
      p->killed = 1;
    int ret = cowhandler(p->pagetable, va);
    if (ret != 0)
      p->killed = 1;
  } else if((which_dev = devintr()) != 0){
    // ok
  } else {
  ...
 }

定义 cowhandler 函数。

int
cowhandler(pagetable_t pagetable, uint64 va)
{
    char *mem;
    if (va >= MAXVA)
      return -1;
    pte_t *pte = walk(pagetable, va, 0);
    if (pte == 0)
      return -1;
    // check the PTE
    if ((*pte & PTE_RSW) == 0 || (*pte & PTE_U) == 0 || (*pte & PTE_V) == 0) {
      return -1;
    }
    if ((mem = kalloc()) == 0) {
      return -1;
    }
    // old physical address
    uint64 pa = PTE2PA(*pte);
    // copy old data to new mem
    memmove((char*)mem, (char*)pa, PGSIZE);
    // PAY ATTENTION
    // decrease the reference count of old memory page, because a new page has been allocated
    kfree((void*)pa);
    uint flags = PTE_FLAGS(*pte);
    // set PTE_W to 1, change the address pointed to by PTE to new memory page(mem)
    *pte = (PA2PTE(mem) | flags | PTE_W);
    // set PTE_RSW to 0
    *pte &= ~PTE_RSW;
    return 0;
}

cowhandler 要进行严格的检查。只有被标记为 COW，存在，且是属于用户级别的，才可以被分配内存。如果本来的页就是只读的，那么在此时尝试对其进行写入，就会返回 -1，最终被杀死。

接着修改 kernel.vm.c 中的 copyout() 函数。这里的思路和 uvmcopy() 中类似。

int checkcowpage(uint64 va, pte_t *pte, struct proc* p) {
  return (va < p->sz) // va should blow the size of process memory (bytes)
    && (*pte & PTE_V) 
    && (*pte & PTE_RSW); // pte is COW page
}

int
copyout(pagetable_t pagetable, uint64 dstva, char *src, uint64 len)
{
    ...
    pa0 = walkaddr(pagetable, va0);
    if(pa0 == 0)
      return -1;

    struct proc *p = myproc();
    pte_t *pte = walk(pagetable, va0, 0);
    if (*pte == 0)
      p->killed = 1;
    // check
    if (checkcowpage(va0, pte, p)) 
    {
      char *mem;
      if ((mem = kalloc()) == 0) {
        // kill the process
        p->killed = 1;
      }else {
        memmove(mem, (char*)pa0, PGSIZE);
        // PAY ATTENTION!!!
        // This statement must be above the next statement
        uint flags = PTE_FLAGS(*pte);
        // decrease the reference count of old memory that va0 point
        // and set pte to 0
        uvmunmap(pagetable, va0, 1, 1);
        // change the physical memory address and set PTE_W to 1
        *pte = (PA2PTE(mem) | flags | PTE_W);
        // set PTE_RSW to 0
        *pte &= ~PTE_RSW;
        // update pa0 to new physical memory address
        pa0 = (uint64)mem;
      }
    }

    n = PGSIZE - (dstva - va0);
    if(n > len)
      n = len;
    ...
}

使用 checkcowpage 检测 PTE 的标志。uvmunmap 函数将 PTE 置零，并 kfree PTE 引用的物理页，其实这里的 kfree 就是将 PTE 引用的物理页的引用计数减一。因为 copyout 分配的一个新的物理页，所以不需要共享之前的旧页了。

由于 uvmunmap 将 PTE 置零，所以 uint flags = PTE_FLAGS(*pte); 必须在其前面。

具体代码

具体的代码变动，请见 GitHub Comment.

- https://www.chens.life/posts/mit-xv6-lab5-cow/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议

vcpkg + cmake + vscode 配置教程

Fri, 27 Jan 2023 15:58:36 +0800

Chen's Life https://www.chens.life/posts/vcpkg-cmake-vscode/ -

本文是使用 vcpkg 、cmake 、vscode 进行 C++ 开发的环境配置教程。

环境描述

Linux Debin11 5.15.79.1-microsoft-standard-WSL2
git version 2.30.2
curl 7.74.0
tar (GNU tar) 1.34
cmake version 3.18.4
vcpkg package management program version 2023-01-24
gcc (Debian 10.2.1-6) 10.2.1 20210110

安装 vcpkg

首先安装上述环境工具：

sudo apt install gcc g++ gdb git curl tar make cmake

从 Github 仓库中克隆 vcpkg 的文件：

git clone https://github.com/Microsoft/vcpkg.git

运行初始化脚本：

./vcpkg/bootstrap-vcpkg.sh

注意：这一步将会从 Github 下载文件，使用魔法会更加方便，只需设置一下代理即可：
export http_proxy=ip:port
export https_proxy=ip:port

成功之后，在 vcpkg 文件夹内将会有一个二进制可执行文件 vcpkg，此时即可使用 vcpkg 。

安装所需要的库

使用命令 search 和 install 可以搜索和安装库。例如我将要安装 oatpp Web 框架：

./vcpkg/vcpkg search oatpp
./vcpkg/vcpkg install oatpp[*]:x64-linux

x64-linux 代表安装目标的机器类型。

这一步会从 GitHub 中下载 oatpp 的源代码，所以需要魔法科技。

成功之后会提醒 oatpp 提供了 CMake 目标。

配置 vscode

新建一个项目文件夹，使用 vscode 打开该文件夹。

mkdir oatpp-test
cd oatpp-test
code .

安装 vscode 插件：C/C++ Extension Pack、CMake ，之后重启 vscode。

Ctrl + Shift + p 输入 settings json 开发工作区设置（JSON）。填入：

{
    "cmake.configureSettings": {
      "CMAKE_TOOLCHAIN_FILE": "<path to vcpkg>/scripts/buildsystems/vcpkg.cmake",
      "VCPKG_TARGET_TRIPLET": "x64-linux"
    }
}

注意：将 <path to vspkg> 替换为你的 vcpkg 路径！！！

创建 CMakeLists.txt 文件，填入：

cmake_minimum_required(VERSION 3.18)
project(oatpp-test)
add_executable(oatpp-test main.cpp)
set(CMAKE_CXX_STANDARD 17)

find_package(oatpp CONFIG REQUIRED)

target_link_libraries(oatpp-test PRIVATE oatpp::oatpp oatpp::oatpp-test)

创建 main.cpp 文件，填入：

#include "oatpp/network/Server.hpp"
#include "oatpp/network/tcp/server/ConnectionProvider.hpp"
#include "oatpp/web/server/HttpConnectionHandler.hpp"

class HelloHandler : public oatpp::web::server::HttpRequestHandler {
public:
  std::shared_ptr<OutgoingResponse>
  handle(const std::shared_ptr<IncomingRequest> &request) override {
    OATPP_LOGI("HelloHandler", "this is a request!");
    auto i = request->getHeaders().get("User-Agent")->c_str();
    OATPP_LOGI("HelloHandler", "User-Agent : %s", i);
    return ResponseFactory::createResponse(Status::CODE_200, "Hello World");
  }
};

void run() {

  /* Create Router for HTTP requests routing */
  auto router = oatpp::web::server::HttpRouter::createShared();

  router->route("GET", "/hello", std::make_shared<HelloHandler>());
  /* Create HTTP connection handler with router */
  auto connectionHandler =
      oatpp::web::server::HttpConnectionHandler::createShared(router);

  /* Create TCP connection provider */
  auto connectionProvider =
      oatpp::network::tcp::server::ConnectionProvider::createShared(
          {"localhost", 8000, oatpp::network::Address::IP_4});

  /* Create server which takes provided TCP connections and passes them to HTTP
   * connection handler */
  oatpp::network::Server server(connectionProvider, connectionHandler);

  /* Print info about server port */
  OATPP_LOGI("MyApp", "Server running on port %s",
             connectionProvider->getProperty("port").getData());
  /* Run server */
  server.run();
}

int main() {

  /* Init oatpp Environment */
  oatpp::base::Environment::init();

  /* Run App */
  run();

  /* Destroy oatpp Environment */
  oatpp::base::Environment::destroy();

  return 0;
}

此代码参考 oatpp 官方文档：https://oatpp.io/docs/start/step-by-step/#add-request-handler

Ctrl + Shift + p 输入 cmake configure ，选择 CMake：配置。这将会配置该 CMake 工程项目。

完成之后即可发现 main.cpp 中的代码已经不报错了，在 vscode 底部状态栏也出现了 CMake 工具。

点击 Build 之后再点击最右边的运行箭头，即可编译运行该测试程序。

访问 http://localhost:8000/hello，即可看到字符 Hello World。终端中可以看到访问端的 User-Agent。

- https://www.chens.life/posts/vcpkg-cmake-vscode/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议

xv6-labs-2022 Lab4 traps 答案与解析

Mon, 21 Nov 2022 18:32:42 +0800

Chen's Life https://www.chens.life/posts/mit-xv6-lab4/ -

这个实验将会探索系统调用是如何使用陷阱（trap）实现的。首先将会利用栈做一个热身练习，接下来你将会实现一个用户级陷阱处理（user-level trap handling）的例子。

阅读 xv6 book 第四章节和以下相关文件：

kernel/trampoline.S ：从用户空间到内核空间并返回的汇编代码。

kernel/trap.c：处理所有中断的代码。

开始之前，切换到 trap 分支。

git fetch
git checkout traps
make clean

RISC-V assembly

理解 RISC-V 的汇编代码很重要。使用命令 make fs.img 编译 user/call.c ，这将会生成一个可读的汇编代码文件 user/call.asm 。

阅读 call.asm 中的 g ，f ，和 main 函数。参考这些材料：reference page。

0x1

Which registers contain arguments to functions? For example, which register holds 13 in main’s call to printf?

通过之前的阅读可知，调用函数时的参数传递使用寄存器 a1, a2 等通用寄存器。

阅读 call.asm 文件的第 45 行。

通过阅读 call.asm 文件中的 main 函数可知，调用 printf 函数时，13 被寄存器 a2 保存。

答案：

a1, a2, a3 等通用寄存器；13 被寄存器 a2 保存。

0x2

Where is the call to function f in the assembly code for main? Where is the call to g? (Hint: the compiler may inline functions.)

通过阅读函数 f 和 g 得知：函数 f 调用函数 g ；函数 g 使传入的参数加 3 后返回。

所以总结来说，函数 f 就是使传入的参数加 3 后返回。考虑到编译器会进行内联优化，这就意味着一些显而易见的，编译时可以计算的数据会在编译时得出结果，而不是进行函数调用。

查看 main 函数可以发现，printf 中包含了一个对 f 的调用。

但是对应的会汇编代码却是直接将 f(8)+1 替换为 12 。这就说明编译器对这个函数调用进行了优化，所以对于 main 函数的汇编代码来说，其并没有调用函数 f 和 g ，而是在运行之前由编译器对其进行了计算。

答案：

main 的汇编代码没有调用 f 和 g 函数。编译器对其进行了优化。

0x3

At what address is the function printf located?

通过搜索容易得到 printf 函数的位置。

得到其地址在 0x642。

答案：

0x642

0x4

What value is in the register ra just after the jalr to printf in main?

auipc 和 jalr 的配合，可以跳转到任意 32 位的地址。

具体相关命令介绍请看参考链接：reference1, RISC-V unprivileged instructions.

第 49 行，使用 auipc ra,0x0 将当前程序计数器 pc 的值存入 ra 中。

第 50 行，jalr 1554(ra) 跳转到偏移地址 printf 处，也就是 0x642 的位置。

根据 reference1 中的信息，在执行完这句命令之后，寄存器 ra 的值设置为 pc + 4 ，也就是 return address 返回地址 0x38。

答案：

jalr 指令执行完毕之后，ra 的值为 0x38.

0x5

Run the following code.
unsigned int i = 0x00646c72;
printf("H%x Wo%s", 57616, &i);
What is the output? Here’s an ASCII table that maps bytes to characters.

The output depends on that fact that the RISC-V is little-endian. If the RISC-V were instead big-endian what would you set i to in order to yield the same output? Would you need to change 57616 to a different value?

Here’s a description of little- and big-endian and a more whimsical description.

请查看在线 C Compiler 的运行结果 c++ sell，它打印出了 He110 World。

首先，57616 转换为 16 进制为 e110，所以格式化描述符 %x 打印出了它的 16 进制值。

其次，如果在小端（little-endian）处理器中，数据0x00646c72 的高字节存储在内存的高位，那么从内存低位，也就是低字节开始读取，对应的 ASCII 字符为 rld。

如果在大端（big-endian）处理器中，数据 0x00646c72 的高字节存储在内存的低位，那么从内存低位，也就是高字节开始读取其 ASCII 码为 dlr。

所以如果大端序和小端序输出相同的内容 i ，那么在其为大端序的时候，i 的值应该为 0x726c64，这样才能保证从内存低位读取时的输出为 rld 。

无论 57616 在大端序还是小端序，它的二进制值都为 e110 。大端序和小端序只是改变了多字节数据在内存中的存放方式，并不改变其真正的值的大小，所以 57616 始终打印为二进制 e110 。

关于大小端，参考：CSDN

答案：

如果在大端序，i 的值应该为 0x00646c72 才能保证与小端序输出的内容相同。不用该变 57616 的值。

0x6

In the following code, what is going to be printed after 'y='? (note: the answer is not a specific value.) Why does this happen?
printf("x=%d y=%d", 3);

通过之前的章节可知，函数的参数是通过寄存器a1, a2 等来传递。如果 prinf 少传递一个参数，那么其仍会从一个确定的寄存器中读取其想要的参数值，但是我们并没有给出这个确定的参数并将其存储在寄存器中，所以函数将从此寄存器中获取到一个随机的不确定的值作为其参数。故而此例中，y=后面的值我们不能够确定，它是一个垃圾值。

答案：

y= 之后的值为一个不确定的垃圾值。

Backtrace

打印出 backtrace，这是一个在错误发生时存在于栈中的函数调用列表，有利于调试。寄存器 s0 包含一个指向当前栈帧 stack frame 的指针，我们的任务就是使用栈帧遍历整个栈，打印每一个栈帧中的返回地址 return address。

实现一个 backtrace() 函数在 kernel/printf.c 中，并且在 sys_sleep 中调用它。之后运行 bttest，它将会调用 sys_sleep 。你和输出应该是一个返回地址列表，就像下面那样（可能数字会不同）：

backtrace:
0x0000000080002cda
0x0000000080002bb6
0x0000000080002898

注意事项：

在 kernel/defs.h 中添加函数 backtrace() 的函数声明，以便在 sys_sleep 中调用 backtrace。
GCC 编译器将当前正在执行的函数的帧指针（frame pointer）存储到寄存器 s0 中。在 kernel/riscv.h 中添加以下代码：
1. ```
static inline uint64
r_fp()
{
  uint64 x;
  asm volatile("mv %0, s0" : "=r" (x) );
  return x;
}
```
2. 在 backtrace 中调用此函数，将会读取当前帧指针。r_fp() 使用内联汇编读取 s0。
课堂笔记中有关于栈帧的布局图片。注意，返回地址在帧指针的 -8 偏移量处；前一个帧指针位于当前帧指针的固定偏移量 (-16) 处。
遍历栈帧需要一个停止条件。有用的信息是：每个内核栈由一整个页（4k对其）组成，所有的栈帧都在同一个页上面。你可以使用PGROUNDDOWN(fp) 来定位帧指针所在的页面，从而确定循环停止的条件。

PGROUNDDOWN(fp) 总是表示 fp 所在的这一页的起始位置。

所以要在 printf 中添加该函数：

void
backtrace(void)
{
  uint64 fp_address = r_fp();
  while(fp_address != PGROUNDDOWN(fp_address)) {
    printf("%p\n", *(uint64*)(fp_address-8));
    fp_address = *(uint64*)(fp_address - 16);
  }
}

在 kernel/defs.h 中添加该函数声明：

void            backtrace(void);

在 kerne/riscv.h 中添加 r_sp函数。

static inline uint64
r_sp()
{
  uint64 x;
  asm volatile("mv %0, sp" : "=r" (x) );
  return x;
}

在 kernel/sysproc.c 中的 sys_sleep 函数中添加该函数调用：

void sys_sleep(void){
    ...
    backtrace();
    ...
}

具体文件变动见 github commit.

Alarm

这个练习将会添加一个特性：当一个进程使用 cpu 时，每隔一个特定的时间就提醒进程。如果我们想要限制一个进程使用 cpu 的时间，那么这个练习将会有帮助。

你应该添加一个新的系统调用 sigalarm(interval, handler)。如果一个应用调用了 sigalarm(n, fn)那么这个进程每消耗 n 个 ticks，内核应该确保函数 fn 被调用。当 fn 返回的时候，内核应该恢复现场，确保该进程在它刚才离开的地方继续执行。一个 tick 在 xv6 中是一个相当随意的单位时间，它取决于硬件时钟产生中断的快慢。如果一个应用调用 sigalarm(0, 0) ，内核应该停止产生周期性的警报调用。

在代码库中有 user/alarmtest.c 程序用于检测实验的真确性。将它添加到 Makefile 文件中以便编译它。

alarmtest 在 test0 中调用 sigalarm(2, periodic) ，使内核每隔 2 个 ticks 就调用 periodic 函数。

通过修改内核，使得内核可以调转到位于用户空间的处理函数（alarm handler），它将打印出 “alarm!” 字符。

回忆一下之前的内容以及 xv6 book 中的第四章节的内容。当使用 trap 方式陷入内核的时候，会首先执行 kernel/trampoline.S 中的 uservec ，保存寄存器中的值以便返回时恢复现场，包括 sepc 中断时保存的用户程序的程序计数器（pc）；然后跳转到 kernel/trap.c 中的 usertrap(void) ，检测该中断的类型（是否是系统调用或者是 timer 时钟中断）；然后跳转到 kernel/trap.c 中的 usertrapret(void) ，它将从之前保存的栈帧(trapframe) 中恢复寄存器，其中一个重要的就是 pec ，CPU 从特权模式返回用户模式，将使用 spec 的值恢复 pc 的值，它决定了返回时，CPU 将要执行的用户代码。这一点很重要，我们的代码也是利用这一点，使 CPU 执行我们定义的用户空间中的 alarm handler 函数。

需要注意的是，为了使得从 alarm handler 中返回之后，仍继续执行原用户程序，我们需要保存之前保存在 trapframe 中的寄存器值，并且在 alarm handler 调用 sys_sigreturn 时恢复这些寄存器。

另外，为了保证实验说明中的要求：在 alarm handler 函数未返回之前，不能重复调用 alarm handler。我们需要一个控制这个状态的变量have_return，它将会添加到 struct proc 中。

首先在 kernel/proc.h 中的 proc 结构体中添加需要的内容。

struct proc {
    ...
  // the virtual address of alarm handler function in user page
  uint64 handler_va;
  int alarm_interval;
  int passed_ticks;
  // save registers so that we can re-store it when return to interrupted code.   
  struct trapframe saved_trapframe;
  // the bool value which show that is or not we have returned from alarm handler.
  int have_return;
    ...
}

在 kernel/sysproc.c 中实现 sys_sigalarm 和 sys_sigreturn 。

uint64
sys_sigreturn(void)
{
  struct proc* proc = myproc();
  // re-store trapframe so that it can return to the interrupt code before.
  *proc->trapframe = proc->saved_trapframe;
  proc->have_return = 1; // true
  return proc->trapframe->a0;
}

uint64
sys_sigalarm(void)
{
  int ticks;
  uint64 handler_va;

  argint(0, &ticks);
  argaddr(1, &handler_va);
  struct proc* proc = myproc();
  proc->alarm_interval = ticks;
  proc->handler_va = handler_va;
  proc->have_return = 1; // true
  return 0;
}

注意到一点，sys_sigreturn(void) 的返回值不是 0，而是 proc->trapframe->a0。这是因为我们想要完整的恢复所有寄存器的值，包括 a0。但是一个系统调用返回的时候，它会将其返回值存到 a0 寄存器中，那这样就改变了之前 a0 的值。所以，我们干脆让其返回之前想要恢复的 a0 的值，那这样在其返回之后 a0 的值仍没有改变。

然后修改 kernel/trap.c 中的 usertrap 函数。

void
usertrap(void) {
  ...
    // give up the CPU if this is a timer interrupt.
  if(which_dev == 2) {
    struct proc *proc = myproc();
    // if proc->alarm_interval is not zero
    // and alarm handler is returned.
    if (proc->alarm_interval && proc->have_return) {
      if (++proc->passed_ticks == 2) {
        proc->saved_trapframe = *p->trapframe;
        // it will make cpu jmp to the handler function
        proc->trapframe->epc = proc->handler_va;
        // reset it
        proc->passed_ticks = 0;
        // Prevent re-entrant calls to the handler
        proc->have_return = 0;
      }
    }
    yield();
  }
  ...
}

从内核跳转到用户空间中的 alarm handler 函数的关键一点就是：修改 epc 的值，使 trap 在返回的时候将 pc 值修改为该 alarm handler 函数的地址。这样，我们就完成了从内核调转到用户空间中的 alarm handler 函数。但是同时，我们也需要保存之前寄存器栈帧，因为后来 alarm handler 调用系统调用 sys_sigreturn 时会破坏之前保存的寄存器栈帧(p->trapframe)。

具体代码改动见：github commit.

- https://www.chens.life/posts/mit-xv6-lab4/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议

如何将一个二进制值的指定位设置为指定的值

Mon, 07 Nov 2022 15:47:41 +0800

Chen's Life https://www.chens.life/posts/how-to-set-a-specified-bit-of-a-binary-value-to-a-specified-value/ -

如何将一串二进制的制定位设置为指定的值。假如有一串二进制值 1010 ，要将第二位设置为 0。

异或 ^

首先需要了解异或 ^ 运算符的概念和性质。和 0 异或等于它本身，相同的值异或等于 1。另外一个值得注意的是，一个数和同一个值异或两次等于它本身。

公式

公式：x = ((x&(1 << n)) ^ x) ^ (a << n)。 x 为原值，n 为第 n 个值，a 为想要设置的值（0或1）。

首先 (x&(1 << n)) 的值为：保留第 n 位原来的值，其他位置零。再将此值与原值 x 异或，得到一个值：除了第 n 个值为零，其他位置为原值。（这是因为，与 0 异或的那一位为原值，与相同值异或的那一位为 0）。然后此时，再与 (a << n) 异或，将第 n 位设置为 a （这是因为与 0 异或为其本身）。

过程

1、原值：               1 0 | 1 | 0    x
2、其他位为0：          0 0 | 1 | 0    x & ( 1 << n )
3、待设置的值           0 0 | 0 | 0    a << n
4、将 1 和 2 异或得到： 1 0 | 0 | 0     x & ( 1 << n ) ^ x
5、将 3 和 4 异或得到： 1 0 | 0 | 0     ((x&(1 << n)) ^ x) ^ (a << n)

- https://www.chens.life/posts/how-to-set-a-specified-bit-of-a-binary-value-to-a-specified-value/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议

xv6-labs-2022 Lab3 page tables 答案与解析

Mon, 07 Nov 2022 15:22:44 +0800

Chen's Life https://www.chens.life/posts/mit-xv6-lab3/ -

这个实验中，你将会探索页表，修改它们去加速一些系统调用，查看那些页被访问过。

开始之前，需要将代码仓库切换到 pgtbl 分支。

git fetch
git checkout pgtbl
make clean

Speed up system calls

这个实验的原理就是，将一些数据存放到一个只读的共享空间中，这个空间位于内核和用户之间。这样用户程序就不用陷入内核中，而是直接从这个只读的空间中获取数据，省去了一些系统开销，加速了一些系统调用。这次的任务是改进 getpid() 。

当每一个进程被创建，映射一个只读的页在 USYSCALL （在memlayout.h定义的一个虚拟地址）处。存储一个 struct usyscall （定义在 memlayout.h）结构体在该页的开始处，并且初始化这个结构体来保存当前进程的 PID。这个 lab 中，ugetpid() 已经在用户空间给出，它将会使用 USYSCALL 这个映射。运行 pgtbltest ，如果正确，ugetpid 这一项将会通过。（注意，这个程序包含两个测试，所以不用慌）。

首先在 kernel/proc.h proc 结构体中添加一项指针来保存这个共享页面的地址。

struct proc {
...
  struct usyscall *usyscallpage;  // share page whithin kernel and user
...
}

之后需要在 kernel/proc.c 的 allocproc() 中为其分配空间(kalloc)。并初始化其保存当前进程的PID。

static struct proc*
allocproc(void) {
...
  if ((p->usyscallpage = (struct usyscall *)kalloc()) == 0) {
    freeproc(p);
    release(&p->lock);
    return 0;
  }

  p->usyscallpage->pid = p->pid;
  
  // Set up new context to start executing at forkret,
  // which returns to user space.
  memset(&p->context, 0, sizeof(p->context));
  p->context.ra = (uint64)forkret;
  p->context.sp = p->kstack + PGSIZE;
...
}

然后在 kernel/proc.c 的 proc_pagetable(struct proc *p) 中将这个映射（PTE）写入 pagetable 中。权限是用户态可读。

pagetable_t
proc_pagetable(struct proc *p) {
...
    if(mappages(pagetable, USYSCALL, PGSIZE, (uint64)(p->usyscallpage), PTE_R | PTE_U) < 0) {
    uvmfree(pagetable, 0);
    return 0;
  }
  // map the trampoline code (for system call return)
  // at the highest user virtual address.
  // only the supervisor uses it, on the way
...
}

之后要确保释放进程的时候，能够释放该共享页。同样在 kernel/proc.c 中的 freeproc(struct proc *p) 。

static void
freeproc(struct proc *p) {
  if(p->trapframe)
    kfree((void*)p->trapframe);
  p->trapframe = 0;
  // add start
  if(p->usyscallpage)
    kfree((void *)p->usyscallpage);
  p->usyscallpage = 0;
  // add end
  if(p->pagetable)
    proc_freepagetable(p->pagetable, p->sz);
}

此刻完成之后，运行 qemu 会 panic 错误。

xv6 kernel is booting

hart 2 starting
hart 1 starting
panic: freewalk: leaf

这是因为在 pagetable 中任然存在我们之前的 PTE 映射。我们需要在 kernel/proc.c 的 proc_freepagetable(pagetable_t pagetable, uint64 sz) 中对其取消映射。

void
proc_freepagetable(pagetable_t pagetable, uint64 sz) {
  uvmunmap(pagetable, TRAMPOLINE, 1, 0);
  uvmunmap(pagetable, TRAPFRAME, 1, 0);
  uvmunmap(pagetable, USYSCALL, 1, 0); // add
  uvmfree(pagetable, sz);
}

具体的代码改动见 github commit。

注：proc_pagetable(struct proc *p) 中映射 PTE 时的权限应该为 PTE_R | PTE_U 而不是 PTE_R | PTE_U | PTE_W。

运行 ./grade-lab-pgtbl ugetpid 即可得到成功信息。或者在 qemu 中运行 pgtbltest 。此时 pgaccess_test 会失败，这个是下面的任务。

Print a page table

第二个任务是写一个函数来打印页表的内容。这个函数定义为 vmprint() 。它应该接收一个 pagetable_t 类型的参数，并且按照下面的格式打印。在 exec.c 中的 return argc 之前插入 if(p->pid==1) vmprint(p->pagetable) ，用来打印第一个进程的页表。

当你做完这些之后，运行 qemu 之后应该看到一下输出，它在第一个进程 init 完成之前打印出来。

page table 0x0000000087f6b000
 ..0: pte 0x0000000021fd9c01 pa 0x0000000087f67000
 .. ..0: pte 0x0000000021fd9801 pa 0x0000000087f66000
 .. .. ..0: pte 0x0000000021fda01b pa 0x0000000087f68000
 .. .. ..1: pte 0x0000000021fd9417 pa 0x0000000087f65000
 .. .. ..2: pte 0x0000000021fd9007 pa 0x0000000087f64000
 .. .. ..3: pte 0x0000000021fd8c17 pa 0x0000000087f63000
 ..255: pte 0x0000000021fda801 pa 0x0000000087f6a000
 .. ..511: pte 0x0000000021fda401 pa 0x0000000087f69000
 .. .. ..509: pte 0x0000000021fdcc13 pa 0x0000000087f73000
 .. .. ..510: pte 0x0000000021fdd007 pa 0x0000000087f74000
 .. .. ..511: pte 0x0000000020001c0b pa 0x0000000080007000
init: starting sh

注意点：

可以将 vmprint() 实现到 kernel/vm.c 中。
使用在 kernel/riscv.h 文件末尾的宏定义。
函数 freewalk 的实现方法对本实验很有帮助。
将函数 vmprint 的声明放到 kernel/defs.h 中，以便可以在 exec.c 中调用它。
使用 %p 格式化打印64位十六进制的 PTEs 和地址。

值得注意的是 freewalk 函数的具体实现。该函数会释放所有的页表（page-table pages），使用递归的形式访问到每一个子页面。

我们此次的 vmprint 函数也可以效仿此递归方法，但是需要展示此页表的深度，这时我们可以另外设置一个静态变量来指示当前打印页的深度信息，如果需要进入下一级页表就将其加一，函数返回就减一。具体实现如下：

void
vmprint(pagetable_t pagetable)
{
  if (printdeep == 0)
    printf("page table %p\n", (uint64)pagetable);
  for (int i = 0; i < 512; i++) {
    pte_t pte = pagetable[i];
    if (pte & PTE_V) {
      for (int j = 0; j <= printdeep; j++) {
        printf("..");
      }
      printf("%d: pte %p pa %p\n", i, (uint64)pte, (uint64)PTE2PA(pte));
    }
    // pintes to lower-level page table
    if((pte & PTE_V) && (pte & (PTE_R|PTE_W|PTE_X)) == 0){
      printdeep++;
      uint64 child_pa = PTE2PA(pte);
      vmprint((pagetable_t)child_pa);
      printdeep--;
    }
  }
}

详细文件改动见：github commit

Detect which pages have been accessed

首先需要了解的是，在一个 Risc V Sv32 page table 包含了 2^10 个 PTEs，每一个 4 bytes。Sv32 PTE 的图示如下：

参考 RISC-V privileged architecture manual 的 P68 及以下几页。

Each leaf PTE contains an accessed (A) and dirty (D) bit. The A bit indicates the virtual page has been read, written, or fetched from since the last time the A bit was cleared. The D bit indicates the virtual page has been written since the last time the D bit was cleared.

（A）位代表此虚拟页被访问（读，写，获取）自上次（A）位被清理（置零）。

这个实验中，我们将实现一个系统调用 sys_pgaccess() 在文件 kernel/sysproc.c 中。这个系统调用会告诉我们哪一个页被访问过。此系统调用接收三个参数。第一：被检查的第一个用户页的起始虚拟地址；第二：被检查页面的数量；第三：接收来自用户地址空间的一个 buffer 地址，将结果以掩码（bitmask）的形式写入。（掩码 bitmask 就是一个数据结构，其一个位代表一个页面，第一个页代表最低有效位）。

注意：

在 user/pgtlbtest.c 的 pgacess_test() 展示了如何使用 pgacess 。
使用 argaddr() 和 argint() 获取参数。
对于要返回的 bitmask 值，在 kernel 中建立临时的buffer，然后使用 copyout 拷贝到用户空间（user space）。
可以限制可以被扫描的页的最大数量（我的实现中没有设置）。
在 kernel/vm.c 中的 walk() 很有用。它可以找到一个虚拟地址对应的 PTE，返回其 physical address。
需要在 kernel/riscv.h 中定义一个 PTE_A，其为 Risc V 定义的 access bit。详细信息查看 RISC-V privileged architecture manual 。
检查完 PTE_A 位时候设置之后，确保将其清零。因为如果不清零，那么这些位都将会被设置为 1 。因为检查其是否设置这个过程就访问了此页面，在之后的过程中不能确定该页面（被检查之前）是否被访问过。
vmprint() 可能会在调试页表时很有用。

walk() 函数的使用非常重要，它可以找到一个虚拟地址对应的 PTE 的地址。而我们就是需要检查 PTE 来判断其是否被访问过（PTE_A 是否被设置）。

另一个重要的是要在检查之后清零此 PTE_A 位，其在 PTE 的第 6 位（从零开始）。如何将一个二进制值的指定位设置为指定的值呢？

公式：x = ((x&(1 << n)) ^ x) ^ (a << n)，详细解释见文章：如何将一个二进制值的指定位设置为指定的值。

实现如下：

int
sys_pgaccess(void)
{
  uint64 va;
  int pagenum;
  uint64 abitsaddr;
  argaddr(0, &va);
  argint(1, &pagenum);
  argaddr(2, &abitsaddr);

  uint64 maskbits = 0;
  struct proc *proc = myproc();
  for (int i = 0; i < pagenum; i++) {
    pte_t *pte = walk(proc->pagetable, va+i*PGSIZE, 0);
    if (pte == 0)
      panic("page not exist.");
    if (PTE_FLAGS(*pte) & PTE_A) {
      maskbits = maskbits | (1L << i);
    }
    // clear PTE_A, set PTE_A bits zero
    *pte = ((*pte&PTE_A) ^ *pte) ^ 0 ;
  }
  if (copyout(proc->pagetable, abitsaddr, (char *)&maskbits, sizeof(maskbits)) < 0)
    panic("sys_pgacess copyout error");

  return 0;
}

全部文件改动见 github commit.

- https://www.chens.life/posts/mit-xv6-lab3/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议

xv6-labs-2022 Lab2 system call 答案与解析

Wed, 02 Nov 2022 20:22:44 +0800

Chen's Life https://www.chens.life/posts/mit-xv6-lab2/ -

本实验将会学习如何使用 GDB 进行调试，以及实现两个系统调用函数（System Call）。

在开始之前，应该将 git 切换到 syscall 分支。

cd xv6-labs-2022
git checkout syscall
make clean

Using gdb

首先应该学习如何使用 GDB 进行调试本 xv6。查看此页面获得信息。

需要注意的是，在 Ubuntu 20.04.5 LTS 中，需要安装并使用 gdb-multiarch，只有这样才可以调试 riscv64程序。

进入 xv6-labs-2022文件夹中。

在终端中输入 make qemu-gdb ，这将运行 qemu 并开启调试功能，在这里，端口为本地的 26000。此时再打开一个终端，运行 gdb-multiarch -x .gdbinit。这将运行 .gdbinit 中的命令，也就是开启远程调试功能，并设置arch架构为 riscv64。具体可以查看此 .gdbinit文件。

需要注意的是，如果 gdb 重新运行，那么 qemu 也应该重新运行。否则可能会出现意想不到的问题。

0x1

在 GDB 中运行以下指令。

(gdb) b syscall
Breakpoint 1 at 0x80001fe0: file kernel/syscall.c, line 133.
(gdb) c
Continuing.
[Switching to Thread 1.3]

Thread 3 hit Breakpoint 1, syscall () at kernel/syscall.c:133
133     {
(gdb) layout src
(gdb) backtrace

b syscall 将在函数 syscall 处设置断点； c 将会运行到此断点时等待调试指令；layout src 将会开启一个窗口展示调试时的源代码；backtrace 将会打印堆栈回溯（stack backtrace)。

那么第一个问题：

Looking at the backtrace output, which function called syscall?

通过堆栈回溯可以看到，函数 usertrap() 调用了 syscall() 函数。

0x2

输入几个n 命令，使其执行 struct proc *p = myproc(); 并打印 *p 的值，它是一个 proc 结构体。

(gdb) n
(gdb) n
(gdb) p/x *p

那么第二个问题：

What is the value of p->trapframe->a7 and what does that value represent? (Hint: look user/initcode.S, the first user program xv6 starts.)

输入命令查看 p->trapframe->a7 的值是多少。

(gdb) p p->trapframe->a7
$2 = 7
(gdb)

得到 a7 的值为 7 。根据参考教材 xv6 book 第二章和 user/initcode.S 中的代码可知，这个 a7 寄存器中保存了将要执行的系统调用号。这里的系统调用号为 7，在 kernel/syscall.h 中可以找到，这个系统调用为 SYS_exec 。

0x3

系统调用运行在内核模式（kernel mode)，可以通过 Supervisor Status Register (sstatus) 来查看当前 CPU 的状态。具体参看官方 RISC-V privileged instructions 文档 4.1.1 章节。

输入 GDB 命令来查看 sstatus 寄存器。通过 p/t 以二进制打印。

(gdb) p/t $sstatus
$4 = 100010
(gdb)

这是官方文档关于 sstatus 寄存器的图示。参考 RISC-V Privilieged ISA。和以下解释：

The SPP bit indicates the privilege level at which a hart was executing before entering supervisor mode. When a trap is taken, SPP is set to 0 if the trap originated from user mode, or 1 otherwise. When an SRET instruction (see Section 3.3.2) is executed to return from the trap handler, the privilege level is set to user mode if the SPP bit is 0, or supervisor mode if the SPP bit is 1; SPP is then set to 0.

SPP 位指示进入管理员模式之前 hart 执行的特权级别。当采取陷阱时，如果陷阱源自用户模式，则 SPP 设置为 0，否则设置为 1。当执行 SRET 指令（见第 3.3.2 节）从陷阱处理程序返回时，如果 SPP 位为 0，则特权级别设置为用户模式，如果 SPP 位为 1，则设置为超级用户模式；然后将 SPP 设置为 0。

根据 sstatus 的二进制值 100010 可知，SPP 位是 0，那么在执行系统调用陷入内核之前的特权级别就是 user mode.

所以问题：

What was the previous mode that the CPU was in?

答案就是：用户模式（User Mode）。

0x4

在后续的实验中，我们编写的代码可能会使内核崩溃(panic)。例如替换 syscall() 函数中的 num = p->trapframe->a7; 为 num = * (int *) 0;，然后运行 make qemu。这样会看到一个 panic 信息。

注：syscall 函数位于 kernel/syscall.c 132行。

xv6 kernel is booting

hart 2 starting
hart 1 starting
scause 0x000000000000000d
sepc=0x0000000080001ff4 stval=0x0000000000000000
panic: kerneltrap

这里的 sepc 指代内核发生 panic 的代码地址。可以在 kernel/kernel.asm 中查看编译后的完整内核汇编代码，在其中搜索这个地址既可以找到使内核 panic 的代码。sepc 的值不是固定不变的。

在这里是 0x0000000080001ff4，所以我在 kernel/kernel.asm 中搜索 80001ff4。

可以看到，果然是 num = * (int *) 0; 使内核 panic。对应的汇编则是 lw a3,0(zero)。一些 risc v 的汇编指令的简单介绍看这里 RISC-V Assembly Language。

所以这条汇编代码代表：将内存中地址从 0 开始的一个字 word （2 bytes) 大小的数据加载到寄存器 a3 中。

那么问题：

Write down the assembly instruction the kernel is panicing at. Which register corresponds to the varialable num?

答案就是：内核 panic 在 lw a3,0(zero)。num 代表 a3 寄存器。

0x5

再次运行虚拟器和 GDB 调试。将断点设置在发生 panic 处。

(gdb) b *0x0000000080001ff4
Breakpoint 1 at 0x80001ff4: file kernel/syscall.c, line 138.
(gdb) c
Continuing.

Thread 1 hit Breakpoint 1, syscall () at kernel/syscall.c:138
(gdb) layout asm
(gdb) n
(gdb) Ctrl + C # 键盘输入结束Thread
(gdb) p $scause
$1 = 13

再次输入 n 之后会发生 panic，此时输入 Ctrl + C 结束。查看 scase 寄存器，它代指内核 panic 的原因，查看文档RISC-V privileged instructions 4.1.8 章节。下面是 Exception Code 图标。

所以这里的 13 代表 Load page fault 。就是从内存地址 0 中加载数据到寄存器 a3 时出错。那么地址 0 处是什么数据呢？从本教材 book-riscv-rev3.pdf 的 Figure 3.3 中可以找到答案。

可以看到，在左侧 Virtual Address 中的地址 0 处对应右侧 Physical Address 的 Unused，表示这个地址没有被使用。而 Kernel 是从虚拟地址的 0x80000000 处开始的。

那么问题：

Why does the kernel crash? Hint: look at figure 3-3 in the text; is address 0 mapped in the kernel address space? Is that confirmed by the value in scause above? (See description of scause in RISC-V privileged instructions)

答案：内核因为加载了一个未使用的地址 0 处的内存数据而崩溃（Load page fault）。地址 0 并不映射到内核空间中（从 0x80000000 开始）。scause 中的异常代码证实了上述观点。

0x5

上述 scuase 指明了内核 panic 的原因。但是有时候我们需要知道，是哪一个用户程序调用 syscall 时发生了 panic。这可以通过打印 proc 结构体中的 name 来查看。

重新启动 qemu 和 gdb。

(gdb) b syscall
Breakpoint 1 at 0x80001fe0: file kernel/syscall.c, line 133.
(gdb) c
Continuing.
[Switching to Thread 1.3]

Thread 3 hit Breakpoint 1, syscall () at kernel/syscall.c:133
133     {
(gdb) layout src
(gdb) n
(gdb) n
(gdb) p p->name
$1 = "initcode\000\000\000\000\000\000\000"
(gdb)

可以看到，这个用户程序是 initcode ，也是 xv6 第一个 process。

打印 proc 结构体可以查看这个进程的其他信息。

(gdb) p *p
$3 = {lock = {locked = 0, name = 0x80008178 "proc", cpu = 0x0}, state = RUNNING, chan = 0x0, killed = 0, xstate = 0,
  pid = 1, parent = 0x0, kstack = 274877894656, sz = 4096, pagetable = 0x87f73000, trapframe = 0x87f74000, context = {
    ra = 2147488870, sp = 274877898368, s0 = 274877898416, s1 = 2147519792, s2 = 2147518720, s3 = 1, s4 = 0, s5 = 3,
    s6 = 2147588560, s7 = 8, s8 = 2147588856, s9 = 4, s10 = 1, s11 = 0}, ofile = {0x0 <repeats 16 times>},
  cwd = 0x80016e40 <itable+24>, name = "initcode\000\000\000\000\000\000\000"}
(gdb)

可以看到，这个initcode 的 pid 为 1.

问题：

What is the name of the binary that was running when the kernel paniced? What is its process id (pid)?

答案：这个二进制的名字为 initcode ，其 process id 为 1.

注：一些调试的方法可以看官网的PPT Using the GNU Debugger 和 guidance page 。

System call tracing

此任务会增加一个系统调用追踪功能，它将会在后续实验的调试时有所帮助。课程提供了一个 trace 程序，它将会运行并开始另一个程序的系统调用追踪功能（tracing enable），此程序位于 user/trace.c。其参数为一个掩码 mask ，用来指示其要追踪的系统调用。例如 trace(1 << SYS_fork)，SYS_fork 为系统调用号在文件 kernel/syscall.h 中。如果系统调用号被设置在掩码中，你必须修改 xv6 内核，当每一个追踪的系统调用将要返回的时候打印一行信息。这一行信息包含进程 id，系统调用的名字和要返回的值。你不需要打印系统调用的参数。trace 系统调用应该启用它调用的程序和它调用程序的每一个子程序的追踪功能，但是不能影响其他进程。

注意事项：

将 $U/_trace 添加到 Makefile 的 UPROGS 中。
运行 make qemu ，将会发现无法编译 user/trace.c，这是因为编译器无法找到这个 trace 系统调用的定义。在 user/user.h 中添加这个系统调用的函数原型；在 user/usys.pl 中添加一个 entry ，它将会生成 user/usys.S ，里面包含真实的汇编代码，它使用 Risc V 的 ecall 指令陷入内核，执行系统调用；在 kernel/syscal.h 中添加一个系统调用号。做完这些，make qemu 就不会报错了。
在 kernel/sysproc.c 中添加一个 sys_trace() 函数作为系统调用。它通过将它的参数保存到 proc 结构体（见 kernel/proc.h）中的新变量中，来实现其功能。从用户空间获取系统调用参数的函数位于 kernel/syscall.c 中，用法例子见 kernel/sysproc.c。
修改 fork() （位于 kernel/proc.c），从父程序拷贝追踪掩码（mask）到子进程。
在 kernel/syscall.c修改 syscall()，以此来打印系统调用 trace。你需要添加一个系统调用名字数组，用来索引。

这个问题的关键在于，如何指定在 syscall() 函数中只打印指定 syscall number 的信息。那么这个掩码 mask 就很重要。

例如 1 << SYS_read，相当于 1 << 5，其二进制值为 100000，那么这个二进制的第五位（如果从 0 开始算）为 1，就证明系统调用号为 5 的需要被打印。

又例如官网上的例子中 trace trace 2147483647 这里 2147483647就是二进制的 01111111111111111111111111111111，其低31为全部为 1 ，就证明 30号（包括30号）以下的系统调用都需要跟踪）。

可以使用一个 mask 来判断已知的系统调用是否需要跟踪打印。如下：

if ( (mask >> num) & 0b1 )
    output

也就是判断那一位是否为 1 ，来判断其是否需要打印。

答案

文件变动见 commit lab2 trace，共修改了 8 个文件。

可通过运行 ./grade-lab-syscall trace 进行测试。

Sysinfo

这个部分将会实现一个系统调用 sysinfo，它将收集正在运行的系统（xv6）的信息。此 system call 需要一个参数：一个指向 struct sysinfo 的指针（见 kernel/sysinfo.h）。在陷入内核后，内核将会填充这个结构体中的字段：freemem 使系统剩余内存（free memory）的数量（单位 bytes），nproc 将会被设置为进程状态 state 不是 UNSED 的进程数量。我们提供了一个测试程序 sysinfotest，如果它打印 “sysinfotest: OK” ，那么就通过了测试。

注意事项：

具体一般信息看官方的 hints。
sysinfo 有一个参数来自于用户空间 use space ，所以需要将内核空间（kernel space）中的数据（struct sysinfo）填充（复制）到用户空间中的结构体中。这个需要用到 copyout，具体例子请看 sys_fstat()(kernel/sysfile.c) 和 filestat()(kernel/file.c)。
在 kernel/kalloc.c 中添加一个函数用于计算未使用的空闲内存。
在 kernel/proc.c 中添加一个函数用于收集进程数量。
这些函数的实现，可以参考其他官方的函数，会有一些启发。

答案

文件改动见 commit lab2 sysinfo，共修改了 9 个文件。

可通过运行 `./grade-lab-syscall sysinfo 进行测试。

- https://www.chens.life/posts/mit-xv6-lab2/ - flyto2035. 本站遵循 CC-BY-NC 4.0 协议