仅记录IP的简单情况使用sudo perf kvm --guest record完成。

uftrace

uftrace 是一个很好的用户空间程序跟踪工具，对于已插入本机Rust二进制的跟踪效果很好。

由于它有很多功能，包含了很多代码。对我们来说最相关的部分是libmcount。这是一个与LD_PRELOAD一起使用的库，它提供了对插入程序的mcount()调用的支持。尽管libmcount可以无依赖构建，但还有很多可选的依赖项，默认情况下都会使用。我只需要它的一小部分。

由于libmcount旨在用于用户空间跟踪，而我想要将其嵌入Hermit内核，因此出现了一些问题。

• 使用共享内存，通过文件'mounted'来在mcount和uftrace之间通信跟踪结果，这尚未在Hermit中实现。
• 所有参数都通过环境变量传递，这在跟踪Hermit时设置起来很烦人。
• 没有方便的开关。我们不能跟踪一切，特别是早期引导。
• 用C编写 -> 总是需要gcc工具链。

由于它的跟踪格式相当简单，这个crate生成一个兼容的格式，这样我们就可以使用围绕uftrace的工具来查看和进一步转换它。

穷人版分析器

Poor Mans Profiler 是一个简单的bash脚本，它循环调用gdb。我们可以使用它来暂停支持gdb良好的qemu，打印完整的回溯，然后立即退出。如果我们经常这样做，我们就有一个相当慢但还不错的采样分析器。

这种调用需要约0.15秒。但大多数时间都花在了gdb启动上。我已经对其进行了一些优化，并使用gdb-python文件来执行相同的操作而无需每次都重启gdb。这将暂停时间减少到约15ms，提高了10倍。但这仍然相当慢。这些not_quite_as_poor_mans_profiler脚本可以在/tools中找到。

不幸的是，virtiofsd包含一个竞争条件，在我们暂停写入/读取文件时会导致它与qemu死锁。修复它并不简单。错误报告：当qemu停止调试时，virtiofsd发生死锁。由于这正是我们想要基准测试的情况，因此它在这里不适用。

gsingh93 的跟踪

gsingh93的trace 是一个针对需要不稳定的 -Z 仪器-mcount 的不错的解决方案：它使用 proc_macro 递归抽象语法树 (AST)，并在每个函数入口（和潜在退出）处添加跟踪调用。它目前调用 println!() 或 log::trace!()，但可以轻松地更改为其他调用。

这里的问题是 Rust 不支持 'proc_macro 中的非内联模块'，这意味着我们无法轻松地注释一个 crate 中的所有内容。大多数 mod 都必须单独注释，并且它不会递归到依赖中。这个对宏的限制在 Rust 测试 中进行了测试，并在 过程宏和“卫生 2.0”的跟踪问题 中进行了跟踪。

这个 crate 有一个 旧实现，仍然使用编译器插件接口。问题：内部 AST 非常不稳定，crates 代码需要经常适应以保持同步。

si_trace_print

si_trace_print 是“堆栈缩进的跟踪打印”。这是一个 rust 库，它需要宏语句来打印消息。消息会缩进到堆栈深度，并且可以可选地以函数名开头。

si_trace_print 的目的是成为一个简单的“入门级”跟踪库，以帮助开发人员手动审查单个程序运行。

hawktracer-rust

hawktracer-rust (GitHub) 为亚马逊的 hawktracer 提供了 rust 绑定。这需要使用跟踪点注释您的代码，但如果这是您想要的，这似乎是一个很好的解决方案。

flamegraph-rs

flamegraph-rs 是 perf 的简单前端，因此不能用于我的应用程序。但是，它有一个很棒的 readme，其中涵盖了大量的跟踪背景。

bpftrace

内核虚拟机称为 eBPF 可以做很多事情。它甚至可以用于执行基于样本的剖析

• bpftrace
• Linux 扩展 BPF (eBPF) 跟踪工具
• 它从内核中提取堆栈跟踪，就像 perf 一样（在这种情况下是通过内存映射 BPF_STACK_TRACE 和 bpf_get_stack()）
• 我们也可以使用 eBPF 手动遍历堆栈：Linux eBPF 堆栈跟踪黑客
• 据我所知，没有方法可以通过 ebpf 与 KVM 进行接口！

虚拟机内省

有一组针对 kvm-vmi 的补丁，它允许轻松地进行 Xen/KVM 客户端的调试、监控、分析和模糊测试。不幸的是，这还不是上游的，需要修补内核和 qemu。

不过，正在努力将其合并到主线中：幻灯片：利用 KVM 作为调试平台

内部机制

mcount

有关 mcount() 实现的一些说明。如果您感兴趣，请查看 backend，它有一些注释。一些有趣的观点

由于对 mcount() 的调用仅在函数开头插入，我们检查父函数的返回地址，将其保存在影子栈中，并用跳转函数覆盖它。这个跳转函数将然后从栈中弹出正确的地址并恢复它，同时记录函数已退出。

当仅挂钩 Rust 函数时，LLVM 插入 mcount() 调用，在调用 mcount() 之前保存所有需要的寄存器，并在之后恢复。由于它始终在函数的开头插入，这只会影响函数参数。

尽管如此，我们仍然备份应用程序的潜在参数寄存器，以防万一。至少有一个情况，(诚然是不正确的) 不安全 Rust 代码可以破坏它：使用 asm!，它通过名称访问寄存器而不是依赖于 LLVM 将 Rust 参数名称转换为寄存器。

在编译时实现禁用这种保存的功能相当简单，这样在支持的代码库上跟踪会更快。

在挂钩中断时，我们需要特别小心，因为 mcount 可能现在会在另一个函数的中间被调用，并且不能破坏任何状态。《interruptsafe》功能旨在以较小的运行时成本提供这种额外的安全性。

有关设计函数跟踪器的进一步阅读，请参阅 内核 ftrace 设计。您还可以参考 uftrace 的 libmcount。

时间对齐 客户端 <-> 主机

为了同时从客户机和主机获取跟踪，我们需要一个非常精确且在客户机和主机上恒定的时钟。x86 处理器包含一个时间戳计数器 (TSC)。最初，这个计数器在每个时钟周期增加一次。由于这在具有变化频率和睡眠状态的现代处理器中难以处理，因此引入了两个名为 constant_tsc 和 nonstop_tsc 的功能。有了它们，TSC 具有固定频率，Linux 内核将其称为 tsc_khz。由于操作系统允许写入此计数器，因此 KVM 需要虚拟化它。过去这通过 kvmclock 完成，并在写入或读取 tsc 时触发虚拟机管理程序异常。现代处理器通过偏移和缩放 '寄存器' 实现硬件虚拟化 tsc_offset/tsc_scaling（您可以在 /proc/cpuinfo 中检查您的 CPU 是否支持它）。

KVM 利用这些功能在启动时将我们的虚拟机的 TSC 设置为零。这种行为是不可配置的。幸运的是，我们有两种方法可以确定我们的虚拟机运行的精确偏移：内核跟踪点和 debugfs。

在 /sys/kernel/debug/kvm/33587-20/vcpu0/tsc-offset 可以读取具有 ID 33587-20 的虚拟机的当前 tsc-offset。由于必须在 vm 运行时执行此操作，并且可能无法捕获此值的所有变化，因此我们使用第二种方法。

内核跟踪点 kvm_write_tsc_offset，在以下 补丁 中引入。要注册此跟踪点，可以使用一个小脚本来注册： setup_kvm_tracing.sh。

通常，TSC 运行的频率（tzc_khz）未公开。您可以直接从内核内存中运行以下 gdb 命令作为 root 读取它

gdb /dev/null /proc/kcore -ex 'x/uw 0x'$(grep '\<tsc_khz\>' /proc/kallsyms | cut -d' ' -f1) -batch 2>/dev/null | tail -n 1 | cut -f2

StackOverflow: 在 x86 内核中获取 TSC 速率

未来工作

• 创建一个前端，可以将跟踪输出到网络，因此不需要文件访问
• 存在一个名为 'no_instrument_function' 的 LLVM 属性，尽管 Rust 编译器没有暴露它。在这里添加该属性可能很容易。参见 让将 LLVM 属性附加到 Rust 函数变得容易。这将消除静态库的需求，但仅在我们针对同一目标编译的情况下（不是内核）。
• 添加禁用返回钩子的选项！
• 修复中断
• 修复多核行为

许可证

许可协议为以下之一：

• Apache License，版本 2.0 (LICENSE-APACHE 或 https://apache.ac.cn/licenses/LICENSE-2.0)
• MIT 许可证 (LICENSE-MIT 或 http://opensource.org/licenses/MIT)

任选其一。

贡献

除非您明确声明，否则您根据 Apache-2.0 许可证定义的工作中的任何有意提交的贡献，将按上述方式双许可，不附加任何其他条款或条件。