QEMU跟踪 / QEMU文档翻译: Tracing

原文出处:QEMU当前的文档 qemu/docs/devel/tracing.txt

一、介绍

这篇文档描述了QEMU追踪的整体架构和如何使用追踪功能来进行debug、性能分析或者监测运行状况。

二、快速开始

步骤1. 编译QEMU时带上’simple’trace追踪后端:

步骤2. 创建一个写有你想追踪的事件(events)的文件

步骤3. 运行虚拟机来产生一个追踪文件

步骤4. 以美观的形式打印出二进制的追踪文件Pretty-print the binary trace file:

三、Trace events

1. 设置子文件夹 Sub-directory setup

在源码目录的每个文件夹中都可以在trace-events文件中声明一组静态的trace events。所有包含有trace-events文件的子文件夹必须被列在源码根目录Makefile.objstrace-events-subdirs项中。这样在编译时,被列出的子文件夹的trace-events文件就会被tracetool脚本处理来生成相关的追踪代码。

单独的trace-events文件会被merged到一个trace-events-all文件中,trace-events-all文件也将会被安装到/usr/share/qemu目录中,并改名为trace-events,这个文件最终会被simpletrace.py脚本用作simpletrace数据格式的追踪分析。

在子文件夹中,以下的文件会被自动生成

  • trace.c – the trace event state declarations
  • trace.h – the trace event enums and probe functions
  • trace-dtrace.h – DTrace event probe specification
  • trace-dtrace.dtrace – DTrace event probe helper declaration
  • trace-dtrace.o – binary DTrace provider (generated by dtrace)
  • trace-ust.h – UST event probe helper declarations

子文件夹中的源码文件应该include本地的trace.h文件,同时不用任何其他子文件夹的路径前缀,比如io/channel-buffer.c中这样写来找到io/trace.h文件:

尽管从其他子文件夹也能找到trace.h文件,但是一般不鼓励这样做,强烈推荐所有的events都在对应的子文件夹直接声明。唯一的例外是有一些共享的trace events,它们会在顶层文件夹的trace-events文件中被定义。顶层文件夹生成的trace文件的前缀是trace-root而不是trace,这是为了防止顶层文件夹和当前文件夹中的trace.h文件产生歧义。

2. 使用trace events

Trace events会直接被如下源码唤起:

3. 声明trace events

tracetool脚本生成被所有使用trace events功能的源文件包含的trace.h头文件。由于很多的源文件都包含trace.h,所以它尽量使用最少的数据类型,包含最少的其他的头文件,来保证命名空间的简洁化和编译所需时间、依赖的最小化。

Trace events这样使用数据类型:

  • 定长类型使用stdint.h的类型。很多偏移量和Guest内存地址最好用uint32_tuint64_t,用定长变量而不是大小会随Host操作系统(32bit或64bit)改变的原始变量,这样trace events就不会截断变量值或打断编译。

  • void *来定义结构体或数组。trace.h头文件无法包含所有的用户定义的结构体,所以用void *来定义指向结构体的指针。

  • 其他的变量,用恰当的原始变量(char, int, long)。

格式化字符串应该反应trave event中定义的类型。特别注意分别用PRId64PRIu64来代替int64_tuint64_t类型。这会保证32和64位平台间的移植性。

每个event声明会以event的名字开始,然后是它的参数,最后是一个易于阅读的格式化字符串。比如:

4. 添加新trace events的一些提示

  1. 追踪代码的变化。代码中值得关注的点经常涉及到状态的变化,比如starting, stopping, allocating, freeing。关注状态变化的追踪是好的追踪,因为它们可以被用来理解系统的运行流程。

  2. 追踪Guest的操作。Guest的I/O操作,比如读设备寄存器是好的追踪点,因为这可以用来理解Guest的交互过程。

  3. 用相关的字段,这样有相对独立上下文的的追踪输出更易被理解。比如,追踪一个malloc返回的将在free中被释放的指针,可以将成对的malloc和free联系起来。没有上下文的trace events通常没什么用。

  4. 在trace event的函数名后加入一些其他命名记号。如果一个函数有多个trace events,应该在trace event函数后追加一些用于区别的命名。

四、一般接口和监视器指令

你可以通过头文件trace/control.h提供的不同的后端程序接口,编写query程序来控制trace events的状态。

注意一些后端没有实现部分接口,这会导致QEMU打印一条警告(please refer to
header “trace/control.h” to see which routines are backend-dependent)。

events的状态也可以通过监视器指令(monitor commands)请求或修改:

-trace events=<file>命令行参数可以用来在qemu程序开始时制定<file>中列出的events,这个文件中的每行都包含一个event名字。

如果-trace events=<file>中的行以-开始,这个event就默认为关闭状态。在使用通配符来开启一组events同时又希望关闭其中某个烦人的event时,这种方法很有用。

通配符匹配在监视器指令trave-event和events列表文件中都可以使用。这意味着你可以批量开启或关闭有相同前缀的一组events。比如,有关virtio-blk的所有trace events可以用以下监视器指令开启:

五、Trace后端

“tracetool”脚本负责自动生成了冗长的trace event代码,也保证了trace event的声明和trace backend无关。每个event并没有被绑定到某个特定的trace后端(比如LTTng或SystemTap)。扩展tracetool脚本可以添加对trace后端的支持。

trace后端是在configure的时候被指定的:

./configure --help命令或下文中有支持trace后端的列表。如果多个后端被同时开始,trace信息会被同时发送给所有开启的后端。

如果没有选择某个特定的后端,configure会默认指定log为后端。

下文将分别介绍目前支持的trace后端。

Nop

“nop”后端生成空的trace event函数,所以编译器会把trace events全部优化掉,这样可以做到没有性能的损失。

注意,不论选择什么后端,带有disable属性的events都会使用”nop”后端生成。

Lof

“log”后端直接将trace events输出到标准错误(stderr),这就相当于把trace events都转化为了debug的printf。

这是最简单的后端,而且可以和原本的使用DPRINTF()的代码一起使用。

Simpletrace

“simple”后端支持一般的使用场景,并且就在QEMU的源码树中。它可能不像特定平台或者第三方追踪后端那样强大,但是它一定是可移植的。除非你有特殊的高阶需求,否则这是最被推荐的trace后端。

Ftrace

“ftrace”后端将trace数据写到ftrace marker中。这相当于将trace events发送到ftrace环状缓冲区中,然后你可以拿qemu的trace数据和内核的trace数据(尤其是应用KVM时的kvm.ko内核模块)作比照来看了。

如果你用KVM,在ftrace中开启kvm events:

在用root用户运行qemu后,你就可以得到trace了:

局限性:”ftrace”后端只能在Linux平台使用。

Syslog

“syslog”后端用POSIX的syslogAPI发送trace events,日志被以特定的LOG_DAEMON设备或LOG_PID选项打开(所以events会被打上生成它们的QEMU进程的pid标签)。所有的events会被日志记录在LOG_INFO级别。

注意:syslog可能会因压缩连续重复的trace events或进行速率限制。

局限性:“syslog”后端只能在支持POSIX的系统中使用。

监视器命令

分析trace文件

“simple”后端产生可以被simpletrace.py脚本格式化输出的二进制trace文件。这个脚本需要”trace-events-all”文件和二进制trace两个参数:

你必须确认编译QEMU时用的就是同一个”trace-events-all”文件,否则trace event的声明可能会被改变,进而导致生成不连续的输出。

LTTng 用户空间 Tracer

“ust”后端用LTTng Userspace Tracer库。这个库没有编译到QEMU的监视器命令,所以要用UST工具来进行代替。UST工具可以进行list,
enable/disable, 和dump traces等操作。

对于用户空间的追踪,lttng-tools包被需要。你必须确保当前的用户属于”tracing”用户组,或者在运行任意的QEMU实例前手动运行lttng-sessiond守护进程。

当运行配置适当的QEMU,LTTng就可以进行event操作:

babeltrace工具可以用来在之后查看trace:

SystemTap

“dtrace”后端用”DTrace sdt probes”,但是只被和SystemTap进行了测试。当SystemTap支持被检测到时,一个带有probes包装的.stp文件会被生成来用于脚本中。这步也可以在编译后手动执行,来改变”.stp probes”中二进制文件的名字:

Trace event属性

每个”trace-events-all”文件中的event项,都可以有0个或多个如下属性的前缀,属性由空格分开。

“disable”

如果某个特定的trace event会被调用很多次,这很可能引起肉眼可辨的性能损失,即使evnet是可以编程来关闭了。

这种情况下你可以声明一个有disable属性的event。这会有效地在编译时关闭event(通过使用”nop”后端),因此就没有性能上的影响了(除非你又编辑了trace-events-all文件)。

而且,有些情况下相对复杂的计算会被执行,用来专门产生trace函数的参数。在这些情况下,可以利用编辑TRACE_${EVENT_NAME}_ENABLED这类宏变量,来避免event关闭后由这些计算带来的额外编译,例如:

通过用trace_event_get_state_backends程序,你可以同时检查event是不是被禁止了或者是不是被动态开启了(头文件trace/control.h可以看到更多相关信息)。

“tcg”

通过TCG产生的Guest代码可以用带有tcg事件属性的定义来进行追踪。在内部,这个属性会生成两个event:<eventname>_trans 来追踪翻译时间,<eventname>_exec来追踪运行时间。

也就是说,在TCG代码翻译生成期间,你应该用trace_<eventname>_tcg函数而不是用两个events,这个函数会在Guest代码生成期间动态调用trace_<eventname>_trans,并在生成必要的TCG代码来在Guest代码执行期间调用trans_<eventname>_exec

带有tcg属性的events可以在trace-events文件中被声明,并且混合有原始类型和TCG类型,而且trace_<eventname>_tcg会优雅地把它们转发到trace_<eventname>_transtrace_<eventname>_exec中。由于翻译阶段,TCG的变量值无法被得知,它们会被trace_<eventname>_trans阶段忽略。因此,在trace-events文件的入口需要两种打印格式(以逗号隔开):

例如:

它会马上过调用:

然后会生成TCG代码来调用:
and will generate the TCG code to call:

“vcpu”

有些events追踪特定vCPU,它含蓄地添加一个CPUState*参数,并且扩展追踪打印格式来展示vCPU信息。如果和tcg属性一起用,会添加第二个TCGv_env参数,这个参数必须指向(指向Guest代码运行时的vCPU的)单目标中的全局TCG寄存器(通常是cpu_env变量)。

tcgvcpu属性当前只保证在根目录的./trace-events文件中能用。

以下例子event,

可以被用作:

如果翻译vCPU地址为0xc1,而代码会被执行在0xc2上,以下是示例输出:

发表评论

电子邮件地址不会被公开。 必填项已用*标注