Caffeinated 6.828：实验 6：网络驱动程序

简介

这个实验是默认你能够自己完成的最终项目。

现在你已经有了一个文件系统，一个典型的操作系统都应该有一个网络栈。在本实验中，你将继续为一个网卡去写一个驱动程序。这个网卡基于 Intel 82540EM 芯片，也就是众所周知的 E1000 芯片。

预备知识

使用 Git 去提交你的实验 5 的源代码（如果还没有提交的话），获取课程仓库的最新版本，然后创建一个名为 lab6 的本地分支，它跟踪我们的远程分支 origin/lab6：


athena% cd ~/6.828/lab
athena% add git
athena% git commit -am 'my solution to lab5'
nothing to commit (working directory clean)
athena% git pull
Already up-to-date.
athena% git checkout -b lab6 origin/lab6
Branch lab6 set up to track remote branch refs/remotes/origin/lab6.
Switched to a new branch "lab6"
athena% git merge lab5
Merge made by recursive.
fs/fs.c | 42 +++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
athena%


然后，仅有网卡驱动程序并不能够让你的操作系统接入互联网。在新的实验 6 的代码中，我们为你提供了网络栈和一个网络服务器。与以前的实验一样，使用 git 去拉取这个实验的代码，合并到你自己的代码中，并去浏览新的 net/ 目录中的内容，以及在 kern/ 中的新文件。

除了写这个驱动程序以外，你还需要去创建一个访问你的驱动程序的系统调用。你将要去实现那些在网络服务器中缺失的代码，以便于在网络栈和你的驱动程序之间传输包。你还需要通过完成一个 web 服务器来将所有的东西连接到一起。你的新 web 服务器还需要你的文件系统来提供所需要的文件。

大部分的内核设备驱动程序代码都需要你自己去从头开始编写。本实验提供的指导比起前面的实验要少一些：没有框架文件、没有现成的系统调用接口、并且很多设计都由你自己决定。因此，我们建议你在开始任何单独练习之前，阅读全部的编写任务。许多学生都反应这个实验比前面的实验都难，因此请根据你的实际情况计划你的时间。

实验要求

与以前一样，你需要做实验中全部的常规练习和至少一个挑战问题。在实验中写出你的详细答案，并将挑战问题的方案描述写入到 answers-lab6.txt 文件中。

QEMU 的虚拟网络

我们将使用 QEMU 的用户模式网络栈，因为它不需要以管理员权限运行。QEMU 的文档的这里有更多关于用户网络的内容。我们更新后的 makefile 启用了 QEMU 的用户模式网络栈和虚拟的 E1000 网卡。

缺省情况下，QEMU 提供一个运行在 IP 地址 10.2.2.2 上的虚拟路由器，它给 JOS 分配的 IP 地址是 10.0.2.15。为了简单起见，我们在 net/ns.h 中将这些缺省值硬编码到网络服务器上。

虽然 QEMU 的虚拟网络允许 JOS 随意连接互联网，但 JOS 的 10.0.2.15 的地址并不能在 QEMU 中的虚拟网络之外使用（也就是说，QEMU 还得做一个 NAT），因此我们并不能直接连接到 JOS 上运行的服务器，即便是从运行 QEMU 的主机上连接也不行。为解决这个问题，我们配置 QEMU 在主机的某些端口上运行一个服务器，这个服务器简单地连接到 JOS 中的一些端口上，并在你的真实主机和虚拟网络之间传递数据。

你将在端口 7（echo）和端口 80（http）上运行 JOS，为避免在共享的 Athena 机器上发生冲突，makefile 将为这些端口基于你的用户 ID 来生成转发端口。你可以运行 make which-ports 去找出是哪个 QEMU 端口转发到你的开发主机上。为方便起见，makefile 也提供 make nc-7 和 make nc-80，它允许你在终端上直接与运行这些端口的服务器去交互。（这些目标仅能连接到一个运行中的 QEMU 实例上；你必须分别去启动它自己的 QEMU）

包检查

makefile 也可以配置 QEMU 的网络栈去记录所有的入站和出站数据包，并将它保存到你的实验目录中的 qemu.pcap 文件中。

使用 tcpdump 命令去获取一个捕获的 hex/ASCII 包转储：


tcpdump -XXnr qemu.pcap


或者，你可以使用 Wireshark 以图形化界面去检查 pcap 文件。Wireshark 也知道如何去解码和检查成百上千的网络协议。如果你在 Athena 上，你可以使用 Wireshark 的前辈：ethereal，它运行在加锁的保密互联网协议网络中。

调试 E1000

我们非常幸运能够去使用仿真硬件。由于 E1000 是在软件中运行的，仿真的 E1000 能够给我们提供一个人类可读格式的报告、它的内部状态以及它遇到的任何问题。通常情况下，对祼机上做驱动程序开发的人来说，这是非常难能可贵的。

E1000 能够产生一些调试输出，因此你可以去打开一个专门的日志通道。其中一些对你有用的通道如下：

| 标志 | 含义 |
| |
| tx | 包发送日志 |
| txerr | 包发送错误日志 |
| rx | 到 RCTL 的日志通道 |
| rxfilter | 入站包过滤日志 |
| rxerr | 接收错误日志 |
| unknown | 未知寄存器的读写日志 |
| eeprom | 读取 EEPROM 的日志 |
| interrupt | 中断和中断寄存器变更日志 |

例如，你可以使用 make E1000_DEBUG=tx,txerr 去打开 “tx” 和 “txerr” 日志功能。

注意：E1000_DEBUG 标志仅能在打了 6.828 补丁的 QEMU 版本上工作。

你可以使用软件去仿真硬件，来做进一步的调试工作。如果你使用它时卡壳了，不明白为什么 E1000 没有如你预期那样响应你，你可以查看在 hw/e1000.c 中的 QEMU 的 E1000 实现。

网络服务器

从头开始写一个网络栈是很困难的。因此我们将使用 lwIP，它是一个开源的、轻量级 TCP/IP 协议套件，它能做包括一个网络栈在内的很多事情。你能在 这里 找到很多关于 lwIP 的信息。在这个任务中，对我们而言，lwIP 就是一个实现了一个 BSD 套接字接口和拥有一个包输入端口和包输出端口的黑盒子。

一个网络服务器其实就是一个有以下四个环境的混合体：

• 核心网络服务器环境（包括套接字调用派发器和 lwIP）
• 输入环境
• 输出环境
• 定时器环境

下图展示了各个环境和它们之间的关系。下图展示了包括设备驱动的整个系统，我们将在后面详细讲到它。在本实验中，你将去实现图中绿色高亮的部分。

核心网络服务器环境

核心网络服务器环境由套接字调用派发器和 lwIP 自身组成的。套接字调用派发器就像一个文件服务器一样。用户环境使用 stubs（可以在 lib/nsipc.c 中找到它）去发送 IPC 消息到核心网络服务器环境。如果你看了 lib/nsipc.c，你就会发现核心网络服务器与我们创建的文件服务器 i386_init 的工作方式是一样的，i386_init 是使用 NSTYPENS 创建的 NS 环境，因此我们检查 envs，去查找这个特殊的环境类型。对于每个用户环境的 IPC，网络服务器中的派发器将调用相应的、由 lwIP 提供的、代表用户的 BSD 套接字接口函数。

普通用户环境不能直接使用 nsipc_* 调用。而是通过在 lib/sockets.c 中的函数来使用它们，这些函数提供了基于文件描述符的套接字 API。以这种方式，用户环境通过文件描述符来引用套接字，就像它们引用磁盘上的文件一样。一些操作（connect、accept 等等）是特定于套接字的，但 read、write 和 close 是通过 lib/fd.c 中一般的文件描述符设备派发代码的。就像文件服务器对所有的打开的文件维护唯一的内部 ID 一样，lwIP 也为所有的打开的套接字生成唯一的 ID。不论是文件服务器还是网络服务器，我们都使用存储在 struct Fd 中的信息去映射每个环境的文件描述符到这些唯一的 ID 空间上。

尽管看起来文件服务器的网络服务器的 IPC 派发器行为是一样的，但它们之间还有很重要的差别。BSD 套接字调用（像 accept 和 recv）能够无限期阻塞。如果派发器让 lwIP 去执行其中一个调用阻塞，派发器也将被阻塞，并且在整个系统中，同一时间只能有一个未完成的网络调用。由于这种情况是无法接受的，所以网络服务器使用用户级线程以避免阻塞整个服务器环境。对于每个入站 IPC 消息，派发器将创建一个线程，然后在新创建的线程上来处理请求。如果线程被阻塞，那么只有那个线程被置入休眠状态，而其它线程仍然处于运行中。

除了核心网络环境外，还有三个辅助环境。核心网络服务器环境除了接收来自用户应用程序的消息之外，它的派发器也接收来自输入环境和定时器环境的消息。

输出环境

在为用户环境套接字调用提供服务时，lwIP 将为网卡生成用于发送的包。lwIP 将使用 NSREQ_OUTPUT 去发送在 IPC 消息页参数中附加了包的 IPC 消息。输出环境负责接收这些消息，并通过你稍后创建的系统调用接口来转发这些包到设备驱动程序上。

输入环境

网卡接收到的包需要传递到 lwIP 中。输入环境将每个由设备驱动程序接收到的包拉进内核空间（使用你将要实现的内核系统调用），并使用 NSREQ_INPUT IPC 消息将这些包发送到核心网络服务器环境。

包输入功能是独立于核心网络环境的，因为在 JOS 上同时实现接收 IPC 消息并从设备驱动程序中查询或等待包有点困难。我们在 JOS 中没有实现 select 系统调用，这是一个允许环境去监视多个输入源以识别准备处理哪个输入的系统调用。

如果你查看了 net/input.c 和 net/output.c，你将会看到在它们中都需要去实现那个系统调用。这主要是因为实现它要依赖你的系统调用接口。在你实现了驱动程序和系统调用接口之后，你将要为这两个辅助环境写这个代码。

定时器环境

定时器环境周期性发送 NSREQ_TIMER 类型的消息到核心服务器，以提醒它那个定时器已过期。lwIP 使用来自线程的定时器消息来实现各种网络超时。

Part A：初始化和发送包

你的内核还没有一个时间概念，因此我们需要去添加它。这里有一个由硬件产生的每 10 ms 一次的时钟中断。每收到一个时钟中断，我们将增加一个变量值，以表示时间已过去 10 ms。它在 kern/time.c 中已实现，但还没有完全集成到你的内核中。

练习 1、为 kern/trap.c 中的每个时钟中断增加一个到 time_tick 的调用。实现 sys_time_msec 并增加到 kern/syscall.c 中的 syscall，以便于用户空间能够访问时间。

使用 make INIT_CFLAGS=-DTEST_NO_NS run-testtime 去测试你的代码。你应该会看到环境计数从 5 开始以 1 秒为间隔减少。-DTEST_NO_NS 参数禁止在网络服务器环境上启动，因为在当前它将导致 JOS 崩溃。

网卡

写驱动程序要求你必须深入了解硬件和软件中的接口。本实验将给你提供一个如何使用 E1000 接口的高度概括的文档，但是你在写驱动程序时还需要大量去查询 Intel 的手册。

练习 2、为开发 E1000 驱动，去浏览 Intel 的 软件开发者手册。这个手册涵盖了几个与以太网控制器紧密相关的东西。QEMU 仿真了 82540EM。

现在，你应该去浏览第 2 章，以对设备获得一个整体概念。写驱动程序时，你需要熟悉第 3 到 14 章，以及 4.1（不包括 4.1 的子节）。你也应该去参考第 13 章。其它章涵盖了 E1000 的组件，你的驱动程序并不与这些组件去交互。现在你不用担心过多细节的东西；只需要了解文档的整体结构，以便于你后面需要时容易查找。

在阅读手册时，记住，E1000 是一个拥有很多高级特性的很复杂的设备，一个能让 E1000 工作的驱动程序仅需要它一小部分的特性和 NIC 提供的接口即可。仔细考虑一下，如何使用最简单的方式去使用网卡的接口。我们强烈推荐你在使用高级特性之前，只去写一个基本的、能够让网卡工作的驱动程序即可。

PCI 接口

E1000 是一个 PCI 设备，也就是说它是插到主板的 PCI 总线插槽上的。PCI 总线有地址、数据、和中断线，并且 PCI 总线允许 CPU 与 PCI 设备通讯，以及 PCI 设备去读取和写入内存。一个 PCI 设备在它能够被使用之前，需要先发现它并进行初始化。发现 PCI 设备是 PCI 总线查找已安装设备的过程。初始化是分配 I/O 和内存空间、以及协商设备所使用的 IRQ 线的过程。

我们在 kern/pci.c 中已经为你提供了使用 PCI 的代码。PCI 初始化是在引导期间执行的，PCI 代码遍历PCI 总线来查找设备。当它找到一个设备时，它读取它的供应商 ID 和设备 ID，然后使用这两个值作为关键字去搜索 pci_attach_vendor 数组。这个数组是由像下面这样的 struct pci_driver 条目组成：


struct pci_driver {
uint32_t key1, key2;
int (*attachfn) (struct pci_func *pcif);
};


如果发现的设备的供应商 ID 和设备 ID 与数组中条目匹配，那么 PCI 代码将调用那个条目的 attachfn 去执行设备初始化。（设备也可以按类别识别，那是通过 kern/pci.c 中其它的驱动程序表来实现的。）

绑定函数是传递一个 PCI 函数 去初始化。一个 PCI 卡能够发布多个函数，虽然这个 E1000 仅发布了一个。下面是在 JOS 中如何去表示一个 PCI 函数：

“`
struct pcifunc {
struct pcibus *bus;

uint32_t dev;
uint32_t func;

uint32_t dev_id;
uint32_t dev_class;

uint32_t reg_base[6];
uint32_t reg_size[6];
uint8_t irq_line;

};
“`

上面的结构反映了在 Intel 开发者手册里第 4.1 节的表 4-1 中找到的一些条目。struct pci_func 的最后三个条目我们特别感兴趣的，因为它们将记录这个设备协商的内存、I/O、以及中断资源。reg_base 和 reg_size 数组包含最多六个基址寄存器或 BAR。reg_base 为映射到内存中的 I/O 区域（对于 I/O 端口而言是基 I/O 端口）保存了内存的基地址，reg_size 包含了以字节表示的大小或来自 reg_base 的相关基值的 I/O 端口号，而 irq_line 包含了为中断分配给设备的 IRQ 线。在表 4-2 的后半部分给出了 E1000 BAR 的具体涵义。

当设备调用了绑定函数后，设备已经被发现，但没有被启用。这意味着 PCI 代码还没有确定分配给设备的资源，比如地址空间和 IRQ 线，也就是说，struct pci_func 结构的最后三个元素还没有被填入。绑定函数将调用 pci_func_enable，它将去启用设备、协商这些资源、并在结构 struct pci_func 中填入它。

练习 3、实现一个绑定函数去初始化 E1000。添加一个条目到 kern/pci.c 中的数组 pci_attach_vendor 上，如果找到一个匹配的 PCI 设备就去触发你的函数（确保一定要把它放在表末尾的 {0, 0, 0} 条目之前）。你在 5.2 节中能找到 QEMU 仿真的 82540EM 的供应商 ID 和设备 ID。在引导期间，当 JOS 扫描 PCI 总线时，你也可以看到列出来的这些信息。

到目前为止，我们通过 pci_func_enable 启用了 E1000 设备。通过本实验我们将添加更多的初始化。

我们已经为你提供了 kern/e1000.c 和 kern/e1000.h 文件，这样你就不会把构建系统搞糊涂了。不过它们现在都是空的；你需要在本练习中去填充它们。你还可能在内核的其它地方包含这个 e1000.h 文件。

当你引导你的内核时，你应该会看到它输出的信息显示 E1000 的 PCI 函数已经启用。这时你的代码已经能够通过 make grade 的 pci attach 测试了。

内存映射的 I/O

软件与 E1000 通过内存映射的 I/O（MMIO）来沟通。你在 JOS 的前面部分可能看到过 MMIO 两次：CGA 控制台和 LAPIC 都是通过写入和读取“内存”来控制和查询设备的。但这些读取和写入不是去往内存芯片的，而是直接到这些设备的。

pci_func_enable 为 E1000 协调一个 MMIO 区域，来存储它在 BAR 0 的基址和大小（也就是 reg_base[0] 和 reg_size[0]），这是一个分配给设备的一段物理内存地址，也就是说你可以通过虚拟地址访问它来做一些事情。由于 MMIO 区域一般分配高位物理地址（一般是 3GB 以上的位置），因此你不能使用 KADDR 去访问它们，因为 JOS 被限制为最大使用 256MB。因此，你可以去创建一个新的内存映射。我们将使用 MMIOBASE（从实验 4 开始，你的 mmio_map_region 区域应该确保不能被 LAPIC 使用的映射所覆盖）以上的部分。由于在 JOS 创建用户环境之前，PCI 设备就已经初始化了，因此你可以在 kern_pgdir 处创建映射，并且让它始终可用。

练习 4、在你的绑定函数中，通过调用 mmio_map_region（它就是你在实验 4 中写的，是为了支持 LAPIC 内存映射）为 E1000 的 BAR 0 创建一个虚拟地址映射。

你将希望在一个变量中记录这个映射的位置，以便于后面访问你映射的寄存器。去看一下 kern/lapic.c 中的 lapic 变量，它就是一个这样的例子。如果你使用一个指针指向设备寄存器映射，一定要声明它为 volatile；否则，编译器将允许缓存它的值，并可以在内存中再次访问它。

为测试你的映射，尝试去输出设备状态寄存器（第 12.4.2 节）。这是一个在寄存器空间中以字节 8 开头的 4 字节寄存器。你应该会得到 0x80080783，它表示以 1000 MB/s 的速度启用一个全双工的链路，以及其它信息。

提示：你将需要一些常数，像寄存器位置和掩码位数。如果从开发者手册中复制这些东西很容易出错，并且导致调试过程很痛苦。我们建议你使用 QEMU 的 e1000_hw.h 头文件做为基准。我们不建议完全照抄它，因为它定义的值远超过你所需要，并且定义的东西也不见得就是你所需要的，但它仍是一个很好的参考。

DMA

你可能会认为是从 E1000 的寄存器中通过写入和读取来传送和接收数据包的，其实这样做会非常慢，并且还要求 E1000 在其中去缓存数据包。相反，E1000 使用直接内存访问（DMA）从内存中直接读取和写入数据包，而且不需要 CPU 参与其中。驱动程序负责为发送和接收队列分配内存、设置 DMA 描述符、以及配置 E1000 使用的队列位置，而在这些设置完成之后的其它工作都是异步方式进行的。发送包的时候，驱动程序复制它到发送队列的下一个 DMA 描述符中，并且通知 E1000 下一个发送包已就绪；当轮到这个包发送时，E1000 将从描述符中复制出数据。同样，当 E1000 接收一个包时，它从接收队列中将它复制到下一个 DMA 描述符中，驱动程序将能在下一次读取到它。

总体来看，接收队列和发送队列非常相似。它们都是由一系列的描述符组成。虽然这些描述符的结构细节有所不同，但每个描述符都包含一些标志和包含了包数据的一个缓存的物理地址（发送到网卡的数据包，或网卡将接收到的数据包写入到由操作系统分配的缓存中）。

队列被实现为一个环形数组，意味着当网卡或驱动到达数组末端时，它将重新回到开始位置。它有一个头指针和尾指针，队列的内容就是这两个指针之间的描述符。硬件就是从头开始移动头指针去消费描述符，在这期间驱动程序不停地添加描述符到尾部，并移动尾指针到最后一个描述符上。发送队列中的描述符表示等待发送的包（因此，在平静状态下，发送队列是空的）。对于接收队列，队列中的描述符是表示网卡能够接收包的空描述符（因此，在平静状态下，接收队列是由所有的可用接收描述符组成的）。正确的更新尾指针寄存器而不让 E1000 产生混乱是很有难度的；要小心！

指向到这些数组及描述符中的包缓存地址的指针都必须是物理地址，因为硬件是直接在物理内存中且不通过 MMU 来执行 DMA 的读写操作的。

发送包

E1000 中的发送和接收功能本质上是独立的，因此我们可以同时进行发送接收。我们首先去攻克简单的数据包发送，因为我们在没有先去发送一个 “I’m here!” 包之前是无法测试接收包功能的。

首先，你需要初始化网卡以准备发送，详细步骤查看 14.5 节（不必着急看子节）。发送初始化的第一步是设置发送队列。队列的详细结构在 3.4 节中，描述符的结构在 3.3.3 节中。我们先不要使用 E1000 的 TCP offload 特性，因此你只需专注于 “传统的发送描述符格式” 即可。你应该现在就去阅读这些章节，并要熟悉这些结构。

C 结构

你可以用 C struct 很方便地描述 E1000 的结构。正如你在 struct Trapframe 中所看到的结构那样，C struct 可以让你很方便地在内存中描述准确的数据布局。C 可以在字段中插入数据，但是 E1000 的结构就是这样布局的，这样就不会是个问题。如果你遇到字段对齐问题，进入 GCC 查看它的 “packed” 属性。

查看手册中表 3-8 所给出的一个传统的发送描述符，将它复制到这里作为一个示例：

“`
63 48 47 40 39 32 31 24 23 16 15 0
+|-|-|-|-||-|-|-|-|

via: https://pdos.csail.mit.edu/6.828/2018/labs/lab6/

作者：csail.mit 选题：lujun9972 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出