Intel Processor Trace（三）

文章目录

前言
一、Packet Relationships and Ordering
- 1.1 Packet Blocks
二、Packet Definitions
- 2.1 Taken/Not-taken (TNT) Packet
- 2.2 Target IP (TIP) Packet
- - 2.2.1 IP Compression
  - 2.2.2 Indirect Transfer Compression for Returns (RET)
- 2.3 Deferred TIPs
- 2.4 Packet Generation Enable (TIP.PGE) Packet
- 2.5 Packet Generation Disable (TIP.PGD) Packet
- 2.6 Flow Update (FUP) Packet
- - 2.6.1 FUP IP Payload
- 2.7 Paging Information (PIP) Packet
- 2.8 MODE Packets
- - 2.8.1 MODE.Exec Packet
  - 2.8.2 MODE.TSX Packet
- 2.9 TraceStop Packet
- 2.10 Core:Bus Ratio (CBR) Packet
总结

前言

本节详细介绍“英特尔处理器跟踪”生成的数据包。这对于编写解释代码的开发人员非常有用，解释代码将解码数据包并将其应用于跟踪的源代码。

参考Intel vol3 Chapter 32 Intel® Processor Trace：32.4 Trace Packets and Data Types

一、Packet Relationships and Ordering

在这一节中，介绍了数据包"绑定"的概念，它涉及确定二进制反汇编中给定数据包所指示的变化应用的IP地址。某些数据包的有效负载中包含关联的IP地址（比如FUP、TIP），而对于其他数据包，解码器只需要搜索特定指令（或指令）的下一个实例来确定数据包的绑定（比如TNT）。然而，在许多情况下，解码器需要考虑数据包之间的关系，并利用数据包上下文来确定如何绑定数据包。

下面的32.4.1.1节提供了数据包的详细描述，包括数据包如何与反汇编中的IP地址、其他数据包或根本不绑定进行关联。列出的许多数据包很容易绑定，因为它们只在少数情况下生成。需要更多考虑的数据包通常是"复合数据包事件"的一部分，例如中断、异常和一些指令，其中单个操作（指令或事件）会生成多个数据包。这些复合数据包事件通常以FUP开始，以指示源地址（如果从反汇编中不清楚），并以TIP或TIP.PGD数据包结束，该数据包指示目标地址（如果提供）。在这种情况下，FUP与TIP数据包被称为"耦合"。

耦合的FUP和TIP数据包之间可能存在其他数据包。定时数据包（如TSC、MTC、CYC或CBR）可以在任何时候到达，因此可能干预复合数据包事件。如果操作更改CR3或处理器的执行模式，则会生成状态更新数据包（例如PIP或MODE）。这些中间数据包指示的状态更改应应用于TIP*数据包的IP地址。表32-14提供了复合数据包事件的摘要；有关每个数据包的更多详细信息，请参阅第32.4.1.1节，有关更详细的数据包生成示例，请参阅第32.7节。
在这里插入图片描述

PT跟踪由一系列数据包（具有不同的类型）组成。例如，为了表示条件分支的选择，Intel PT使用的TNT数据包有两种不同的大小：8位和64位。为了重构执行流程，还需要考虑其他一些事情，例如间接分支，函数返回或中断。为了对此建模，英特尔PT添加了更多数据包，例如TIP用于间接分支和函数返回，以及FUP用于异步事件位置。然后，中断将被表示为FUP，后跟一个TIP，分别给出异步分支的源和目的地。英特尔PT还提供有关事务同步的信息。每当事务开始，落实或中止时，Intel PT都会生成两个数据包：MODE.TSX数据包提供新的事务状态，FUP数据包给出了新状态生效的代码位置。对于事务中止，将生成一个附加的TIP数据包，以提供相应中止处理程序的位置。

1.1 Packet Blocks

数据包块是一种用于转储一个或多个状态值组的方法。数据包块以块开始数据包（Block Begin Packet – BBP）开头，该数据包指示块中保存的状态类型。在每个BBP之后可能会有一个或多个块项数据包（Block Item Packets – BIP），其中包含状态值。块由块结束数据包（Block End Packet – BEP）或指示新块开始的另一个BBP终止。

BIP数据包包括一个ID值，该值与其前面的BBP中的类型字段结合使用，唯一地标识BIP有效负载中保存的状态值。每个BIP数据包的有效负载大小由前面的BBP数据包中的大小字段提供。

每个块类型最多可以定义32个项目。但是，并不保证每个该类型的块都包含所有32个项目。有关预期的项目的更多详细信息，请参阅特定感兴趣的块类型的文档。

有关数据包块生成方案的详细信息，请参阅块开始数据包（BBP）的描述（第32.4.2.26节）。

数据包块完全在指令内或指令之间生成，这决定了数据包块中可能出现的数据包类型（除了BIP）。不能在块内生成指示控制流变化或其他指示指令完成的数据包。这些数据包列在下表中。其他数据包，包括定时数据包，可能出现在BBP和BEP之间。

请参阅BBP数据包描述（第32.4.2.26节）以了解有关数据包块生成方案的详细信息。
在这里插入图片描述
在块的中间可能会遇到内部缓冲区溢出。在这种情况下，可以保证数据包生成不会在块的中间恢复，因此溢出（OVF）数据包终止当前块。根据溢出的持续时间，后续块可能也会丢失。

解码器含义（Decoder Implications）
当遇到块开始数据包（BBP）时，它表示数据包块的开始。解码器需要对块内的数据包与块外的数据包进行不同的处理。

在数据包块内部，块项数据包（BIP）用于携带状态值。BIP的头字节与块外的TNT数据包具有相同的编码方式，即遵循TNT编码方案。然而，在数据包块内部，BIP的头字节必须被视为BIP头，表示它后面跟随着包含状态值的有效负载。

BIP的有效负载包含实际的状态值，该值与特定的ID相关联。BIP的ID值与前面的BBP数据包中的类型字段的组合唯一地标识了BIP有效负载中保存的状态值。

需要注意的是，当在数据包块内遇到溢出数据包（OVF）时，它表示内部缓冲区溢出。在这种情况下，解码器应将OVF数据包解释为块结束条件。这意味着数据包生成不会在当前块内恢复。根据溢出的持续时间，后续的数据包块也可能会丢失。

二、Packet Definitions

下面的数据包定义描述以表格格式呈现。图32-3解释了如何解读它们。标记为“RSVD”的数据包位不能保证为0。
在这里插入图片描述
（1）Packet Format：

（2）Dependencies：这取决于数据包生成配置的使能控制或其他位（第32.2.6节）的设置。

（3）Generation Scenario：哪些指令、事件或其他场景可以导致生成此数据包。

（4）Description：数据包的描述，包括其服务的目的、信息或有效载荷的含义等。

（5）Application：解码器应该如何应用此数据包。它可能绑定到二进制中的特定指令，或流中的另一个数据包，或对解码有其他影响。

// processor-trace/libipt/include/intel-pt.h/** Intel PT packet types. */
enum pt_packet_type {/* An invalid packet. */ppt_invalid,/* A packet decodable by the optional decoder callback. */ppt_unknown,/* Actual packets supported by this library. */ppt_pad,ppt_psb,ppt_psbend,ppt_fup,ppt_tip,ppt_tip_pge,ppt_tip_pgd,ppt_tnt_8,ppt_tnt_64,ppt_mode,ppt_pip,ppt_vmcs,ppt_cbr,ppt_tsc,ppt_tma,ppt_mtc,ppt_cyc,ppt_stop,ppt_ovf,ppt_mnt,ppt_exstop,ppt_mwait,ppt_pwre,ppt_pwrx,ppt_ptw
};

2.1 Taken/Not-taken (TNT) Packet

Taken/Not-taken (TNT) Packet
（1）Packet Format：
在这里插入图片描述 B1…BN表示最后N个条件分支或压缩RET（第32.4.2.2节）的结果，其中B1为最旧，BN为最新。短TNT数据包可以包含1到6个TNT位。长TNT数据包可以包含1到47个TNT位。

无论数据包中有多少个TNT位，最后一个有效的TNT位后面都跟随一个尾随的1，即停止位，如上所示。如果TNT数据包不完整（短TNT少于6个TNT位，长TNT少于47个TNT位），停止位向上移动，并且数据包的尾随位填充为0。下面显示了这些“部分TNT”的示例。实现可以选择使用长TNT、短TNT或两者兼用。

在这里插入图片描述

// processor-trace/libipt/src/pt_encoder.cint pt_encode_tnt_8(struct pt_encoder *encoder, uint8_t tnt, int size)
{struct pt_packet packet;packet.type = ppt_tnt_8;packet.payload.tnt.bit_size = (uint8_t) size;packet.payload.tnt.payload = tnt;return pt_enc_next(encoder, &packet);
}int pt_encode_tnt_64(struct pt_encoder *encoder, uint64_t tnt, int size)
{struct pt_packet packet;packet.type = ppt_tnt_64;packet.payload.tnt.bit_size = (uint8_t) size;packet.payload.tnt.payload = tnt;return pt_enc_next(encoder, &packet);
}

（2）Dependencies：PacketEn && ~IA32_RTIT_CTL.DisTNT

（3）Generation Scenario：在条件分支或压缩RET指令中，如果它填满了TNT位，那么就会生成完整的TNT数据包。此外，部分TNT可能在任何时间生成，这是由于在TNT填满之前生成了其他数据包，或者发生了特定的微体系结构条件。

（4）Description：提供了最近1到6个（短TNT）或1到47个（长TNT）条件分支（Jcc、J*CXZ或LOOP）或压缩RET（第32.4.2.2节）的是否执行（taken/not-taken）结果。TNT有效负载位的解释如下：

1表示执行了条件分支或压缩RET指令
0表示未执行条件分支

TNT有效负载位在处理器内部存储在TNT缓冲区中，直到缓冲区填满或生成另一个数据包为止。在任何情况下，将发出包含缓冲位的TNT数据包，并将TNT缓冲区标记为空。

（5）Application：每个有效的有效负载位（即头部位和尾部停止位之间的位）都应用于即将到来的条件分支或RET指令。一旦解码器消耗了一个具有N个有效负载位的TNT数据包，这些位应用于（因此提供了）接下来的N个条件分支或RET指令的目标。

2.2 Target IP (TIP) Packet

Target IP (TIP) Packet
（1）Packet Format
在这里插入图片描述
（2）Dependencies：PacketEn

（3）Generation Scenario：间接分支（包括未压缩的RET）、远分支、中断、异常、INIT、SIPI、VM退出、VM进入、TSX中止、EENTER、EEXIT、ERESUME、AEX1（）。

间接分支（包括未压缩的RET指令）：当执行间接分支指令（如JMP、CALL）或未压缩的RET指令时，可能会生成相应的数据包。远程分支（Far branch）：当执行远程分支指令（如FAR JMP、FAR CALL）时，可能会生成相应的数据包。中断（Interrupt）：当发生中断（如外部硬件中断、软件中断）时，可能会生成相应的数据包。异常（Exception）：当发生异常（如除零错误、页错误）时，可能会生成相应的数据包。INIT、SIPI：当进行初始化（INIT）或引导处理器（SIPI）时，可能会生成相应的数据包。虚拟机退出（VM exit）和虚拟机进入（VM entry）：当虚拟机从宿主机环境退出或进入时，可能会生成相应的数据包。事务中断（TSX abort）：当事务执行中断（如事务冲突）时，可能会生成相应的数据包。EENTER、EEXIT、ERESUME：当执行Intel SGX扩展指令（EENTER、EEXIT、ERESUME）时，可能会生成相应的数据包。AEX1（Asynchronous Enclave Exit 1）：当发生异步的SGX enclave退出时，可能会生成相应的数据包。

EENTER、EEXIT、ERESUME、AEX只能用于调试飞地。

（4）Description：为某些控制流传输提供目标

（5）Application：任何时候遇到TIP，都表示控制权已转移到有效负载中提供的IP。
控制流变化的来源以及与之绑定的IP或指令取决于TIP之前的数据包。如果遇到TIP并且所有之前的数据包已经被绑定，那么TIP将应用于即将到来的间接分支、远程分支或VMRESUME。然而，如果存在一个未被绑定的先前的FUP（Flow Update Packet），它将与TIP进行绑定。在这种情况下，TIP提供了在FUP有效负载中给定的IP处发生的异步事件或TSX中止事件的目标。请注意，除了FUP之外，可能还有其他数据包与TIP数据包进行绑定。有关其他数据包的详细信息，请参阅数据包应用描述。

int pt_enc_next(struct pt_encoder *encoder, const struct pt_packet *packet)
{......switch (packet->type) {case ppt_tip:return pt_encode_ip(encoder, pt_opc_tip, &packet->payload.ip);	}	......
}int pt_encode_tip(struct pt_encoder *encoder, uint64_t ip,enum pt_ip_compression ipc)
{struct pt_packet packet;packet.type = ppt_tip;packet.payload.ip.ip = ip;packet.payload.ip.ipc = ipc;return pt_enc_next(encoder, &packet);
}

2.2.1 IP Compression

在TIP、FUP、TIP.PGE或TIP.PGD数据包中，IP有效负载的大小可以根据执行模式和IP压缩的使用而变化。IP压缩是处理器可以选择使用的一种可选压缩技术，用于减少带宽消耗。使用IP压缩时，要在有效负载中表示的IP与上一次通过FUP、TIP、TIP.PGE或TIP.PGD发送的IP进行比较。如果先前的IP具有相同的上部（最高有效）地址字节，则当前数据包中的匹配字节可以被省略。处理器会维护一个内部状态的“Last IP”（上次编码为追踪数据包的IP），因此解码器需要在软件中跟踪“Last IP”状态，以与硬件生成的数据包保持一致。“Last IP”初始化为零，因此如果追踪中的第一个IP的上部字节为零，则可以压缩该IP的表示形式。

“IPBytes”字段指示在有效负载中显式提供的IP字节数。解码器使用此信息通过将提供的字节与先前的IP的不变字节组合来重构完整的IP。该算法确保只传输IP的不同字节，从而减少了追踪数据所需的带宽。

通过遵循这个算法，解码器可以准确地从TIP/FUP数据包的有效负载中重构IP地址，并与硬件生成的数据包保持一致。
在这里插入图片描述
当发送PSB时，处理器内部的“Last IP”状态被保证重置为零。这意味着在PSB之后的IP要么是未压缩的（011b或110b，参见表格32-18），要么与零进行压缩。

有时，“IPBytes”字段的值为0。如上所示，这并不意味着IP有效负载与上一个IP的完整地址匹配，而是表示此数据包的IP被省略。这用于适用于数据包的IP上下文无关的情况。例如，在仅跟踪用户代码时发送的SYSCALL上发送的TIP.PGD。在这种情况下，数据包中不会包含TargetIP，因为那将暴露具有CPL = 0的指令点。当以这种方式压缩IP有效负载时，“Last IP”不会被清除，而是指向具有非零IPBytes字段的上一个IP数据包。

对于支持最大线性地址大小为32位的处理器，IP有效负载可能永远不会超过32位（IPBytes <= 010b）。

2.2.2 Indirect Transfer Compression for Returns (RET)

除了对IP进行压缩之外，针对近返回（RET）指令的TIP数据包也可以进行压缩。如果RET的目标与相应CALL的下一个IP匹配，则不需要TIP数据包，因为解码器可以通过维护自己的CALL/RET堆栈来推断目标IP。

当RET被压缩时，会在TNT缓冲区中添加一个Taken（已执行）指示。由于RET不生成TIP数据包，它也不会更新内部的Last IP值，因此解码器应该以相同的方式处理它。如果RET没有被压缩，它将生成一个TIP数据包（就像当禁用RET压缩时一样，通过IA32_RTIT_CTL.DisRETC）。

解码器可以通过以下步骤来维护CALL/RET堆栈：
（1）分配空间来存储64个RET目标。
（2）对于近CALL，将Next IP推入堆栈中。一旦堆栈已满，新的CALL将强制最老的条目从堆栈末尾弹出，只存储最新的64个条目。需要注意的是，这不包括长度为零的CALL，它们是直接的近CALL，位移为零（指向下一个IP）。这些CALL通常没有匹配的RET。
（3）对于近RET，从堆栈中弹出顶部（最新的）条目。这将是RET的预期目标。

在RET被压缩的情况下，RET目标与上述第3步中的预期目标保证匹配。如果目标没有被压缩，将生成一个带有RET目标的TIP数据包，该目标在某些情况下可能与预期目标不同。

处理器硬件确保解码器读取的数据包始终会看到与任何压缩RET对应的CALL指令。处理器永远不会在PSB、缓冲区溢出或PacketEn=0的情况下压缩RET。这意味着在PacketEn=0执行期间或在最后一个PSB之前执行的RET将不会被压缩。

如果软件操纵或损坏了CALL/RET堆栈，导致RET将控制转移到与CALL/RET堆栈不一致的目标上，那么RET将不会被压缩，并且会生成一个TIP数据包。例如，如果软件执行PUSH指令将一个目标推入堆栈，然后稍后的RET使用了这个目标，就可能发生这种情况。

对于使用延迟TIP（Section 32.4.2.3）的处理器，未压缩的RET将不会被延迟，因此会强制输出任何累积的TNT或TIP。这可以避免歧义，并清楚地告诉解码器近RET是否被压缩，从而确定是否应该使用in-progress TNT中的一个位，或者是否应该消耗一个TIP，如果近RET未被压缩，则不会有in-progress TNT存在。

请注意，在极少数情况下，如果RET在与相关的CALL不同的执行模式下执行，解码器将需要使用其CALL堆栈模拟相同的行为。例如，如果CALL在64位模式下执行，将会将64位IP值推入软件堆栈。如果相应的RET在32位模式下执行，则只会从堆栈中弹出低32位目标，这可能意味着RET不会跳转到CALL的Next IP。这是符合架构规范的行为，而且该RET可能会被压缩，因此解码器应该匹配此行为。

2.3 Deferred TIPs

处理器可以选择在生成TIP时推迟发送TNT。因此，不是发送部分TNT后跟一个TIP，而是将两个数据包都推迟，同时TNT积累更多的Jcc/RET结果。可以以这种方式累积任意数量的TIP数据包，只有当TNT填满时，或者生成了另一个数据包（例如FUP），TNT将被发送，然后发送所有推迟的TIP数据包，并最后由强制推出TNT和TIP数据包的其他数据包（s）终止。生成许多其他数据包（请参见下面的列表）将强制推出TNT和任何累积的TIP数据包。这是硬件中的一种可选优化，旨在减少追踪时的带宽消耗，从而减少性能影响。
在这里插入图片描述

2.4 Packet Generation Enable (TIP.PGE) Packet

Target IP - Packet Generation Enable (TIP.PGE) Packet
（1）Packet Format
在这里插入图片描述
（2）Dependencies： PacketEn transitions to 1

（3）Generation Scenario：任何分支指令、控制流转移、设置PacketEn的MOV CR3指令，以及启用数据包生成并设置PacketEn的WRMSR指令都可能强制推出TNT和累积的TIP数据包。这些操作会触发数据包生成和传输的相关机制，从而导致已积累的TNT和TIP数据包被发送并终止。

（4）Description：当PacketEn从0转变为1时，表示已经启用了数据包生成，并提供了追踪开始的IP地址。

PacketEn的各个使能位中的任何一个从0到1的转变都可以导致这种情况发生，只要其他使能位都被断言。以下是一些示例：

TriggerEn：当软件写入设置IA32_RTIT_CTL.TraceEn时，只要IA32_RTIT_STATUS中的Stopped和Error位清除，就会设置该使能位。IP载荷将是WRMSR的Next IP。

FilterEn：当软件跳转到追踪区域时，将设置该使能位。该区域由在IA32_RTIT_CTL.ADDRn_CFG中启用IP过滤和在IA32_RTIT_ADDRn_[AB]中定义范围来定义，详见第32.2.5.3节。IP载荷将是分支的目标地址。

ContextEn：当发生CPL更改、CR3写入或其他改变ContextEn的方式时，将设置该使能位。如果更改上下文的指令不是分支指令，则IP载荷将是更改上下文指令的Next IP；如果是分支指令，则IP载荷将是分支的目标地址。

（5）Application： TIP.PGE数据包绑定到有效载荷中给定的IP处的指令。

int pt_enc_next(struct pt_encoder *encoder, const struct pt_packet *packet)
{......switch (packet->type) {case ppt_tip_pge:return pt_encode_ip(encoder, pt_opc_tip_pge,&packet->payload.ip);	}......
}
int pt_encode_tip_pge(struct pt_encoder *encoder, uint64_t ip,enum pt_ip_compression ipc)
{struct pt_packet packet;packet.type = ppt_tip_pge;packet.payload.ip.ip = ip;packet.payload.ip.ipc = ipc;return pt_enc_next(encoder, &packet);
}

2.5 Packet Generation Disable (TIP.PGD) Packet

Target IP - Packet Generation Disable (TIP.PGD) Packet
（1）Packet Format：
在这里插入图片描述
（2）Dependencies：PacketEn transitions to 0

（3）Generation Scenario：清除PacketEn的任何分支指令、控制流传输或MOV CR3，一种禁用数据包生成并清除PacketEn的WRMSR。

（4）Description：当PacketEn从1转变为0时，表示已经禁用了数据包生成，并且将包含追踪结束的IP地址，除非在清除PacketEn的指令或事件的结尾处，ContextEn=0或TraceEn=0。

PacketEn可以由构成PacketEn的任何使能位从1到0的转变而被清除。以下是一些示例：

TriggerEn：当软件写入清除IA32_RTIT_CTL.TraceEn时，或者当设置了IA32_RTIT_STATUS.Stopped，或发生操作错误时，会清除该使能位。在这种情况下，IP载荷将被抑制，并且"IPBytes"字段的值为0。

FilterEn：当软件跳出追踪区域时，将清除该使能位。该区域由在IA32_RTIT_CTL.ADDRn_CFG中启用IP过滤和在IA32_RTIT_ADDRn_[AB]中定义范围来定义，详见第32.2.5.3节。IP载荷将取决于分支的类型。对于条件分支，载荷将被抑制（IPBytes = 0），在这种情况下，可以从反汇编中推断出目标地址。对于其他类型的分支，IP载荷将是分支的目标地址。

ContextEn：当发生CPL更改、CR3写入或其他改变ContextEn的方式时，将清除该使能位。详见第32.2.5.3节。在这种情况
下，当ContextEn被清除时，将没有IP载荷。"IPBytes"字段的值将为0。

需要注意的是，在通常会生成TIP数据包（例如远跳转、间接分支、中断等）或TNT更新（条件分支或压缩RT）的分支导致PacketEn从1转变为0的情况下，TIP或TNT位将被替换为TIP.PGD。TIP.PGD的载荷将是分支的目标地址，除非该指令的结果导致TraceEn或ContextEn被清除（例如，当IA32_RTIT_CTL.OS=0时的SYSCALL）。在清除FilterEn并且因此清除PacketEn的条件分支的情况下，该分支将没有TNT位，而是被TIP.PGD替代。

（5）Application：TIP.PGD可以由任何分支指令以及一些非分支指令清除PacketEn时产生。当由分支指令产生时，它会替代分支通常会生成的任何TIP或TNT更新。

在存在未绑定的FUP指令之前出现TIP.PGD时，TIP.PGD是由清除PacketEn的复合操作（例如异步事件或TSX中止）的一部分。对于大多数这样的情况，TIP.PGD只是替换了一个TIP，并且应该以相同的方式处理。TIP.PGD可能有也可能没有IP载荷，这取决于操作是否清除了ContextEn。

如果没有相关的FUP指令，绑定将取决于是否存在IP载荷。如果存在IP载荷，则TIP.PGD应用于下一个目标与TIP.PGD载荷匹配的直接分支，或者下一个通常会生成TIP或TNT数据包的分支。如果没有IP载荷，则TIP.PGD应用于下一个分支或MOV CR3指令。

int pt_enc_next(struct pt_encoder *encoder, const struct pt_packet *packet)
{......switch (packet->type) {case ppt_tip_pgd:return pt_encode_ip(encoder, pt_opc_tip_pgd,&packet->payload.ip);	}......
}int pt_encode_tip_pgd(struct pt_encoder *encoder, uint64_t ip,enum pt_ip_compression ipc)
{struct pt_packet packet;packet.type = ppt_tip_pgd;packet.payload.ip.ip = ip;packet.payload.ip.ipc = ipc;return pt_enc_next(encoder, &packet);
}

2.6 Flow Update (FUP) Packet

Flow Update (FUP) Packet
（1）Packet Format
在这里插入图片描述
（2）Dependencies：TriggerEn && ContextEn.(Typically depends on BranchEn and FilterEn as well）

（3）Generation Scenario：异步事件（中断、异常、INIT、SIPI、SMI、VM退出、#MC）、PSB+、XBEGIN、XEND、XABORT、XACQUIRE、XRELEASE、EENTER、EEXIT、ERESUME、EEE、AEX、1、INTO、INT1、INT3、INT n，以及禁用数据包生成的WRMSR指令都有可能导致TIP.PGD数据包的生成。

备注：EENTER、EEXIT、ERESUME、EEE和AEX指令仅在支持Intel Software Guard Extensions（Intel SGX）的情况下适用。

（4）Description：TIP.PGD数据包为异步事件以及其他一些指令提供源地址。它永远不会单独发送，而是始终与相关的TIP或MODE数据包以及可能的其他数据包一起发送。

（5）Application：FUP数据包提供它们所绑定的IP地址。然而，它们永远不会独立发送，而是与其他数据包结合在一起发送。

在TSX（事务同步扩展）情况下，FUP数据包之前会紧接着一个MODE.TSX数据包，它与相同的IP地址绑定。只有在TSX中止的情况下，才会跟随一个TIP数据包，详见第32.4.2.8节。

否则，FUP数据包是复合数据包事件的一部分（参见第32.4.1节）。在这些复合事件中，FUP提供了指令或事件的源IP地址，而随后的TIP（或TIP.PGD）数据包将提供目标IP地址。在FUP和TIP之间，可能会包含其他数据包作为复合事件的一部分。

int pt_encode_fup(struct pt_encoder *encoder, uint64_t ip,enum pt_ip_compression ipc)
{struct pt_packet packet;packet.type = ppt_fup;packet.payload.ip.ip = ip;packet.payload.ip.ipc = ipc;return pt_enc_next(encoder, &packet);
}

2.6.1 FUP IP Payload

Flow Update Packet（FUP）在需要时提供指令的源地址。通常情况下，分支指令不需要FUP，因为源地址可以从反汇编中确定。然而，对于异步事件，源地址无法从源代码中推断出来，因此需要发送FUP。

32-23表中，详细说明了发送FUP的情况以及这些情况下可以预期的IP地址。该表列出了特定情况和生成FUP时可能出现的IP值。
在这里插入图片描述
在由于顺序获取非规范空间中的指令（与跳转到非规范空间相反）而导致的规范错误中，错误的IP（因此也是FUP的有效载荷）将是一个非规范地址。这与在此类错误情况下在堆栈上推送的内容是一致的。

如果存在后提交的任务切换错误，那么FUP的IP值将是任务切换开始时的原始IP。这与LBR_FROM字段中的值相同。但与保存在堆栈或VMCS中的值不同。

2.7 Paging Information (PIP) Packet

Paging Information (PIP) Packet
（1）Packet Format
在这里插入图片描述
（2）Dependencies：TriggerEn && ContextEn && IA32_RTIT_CTL.OS

（3）Generation Scenario：MOV CR3, Task switch, INIT, SIPI, PSB+, VM exit, VM entry

（4）Description：CR3负载仅包含CR3值的地址部分。对于PAE分页模式，CR3[11:5]也包含在内。对于其他分页模式（32位和4级分页），这些位将为0。

该数据包保存了CR3地址值。它将在修改CR3的操作中生成，包括：

MOV CR3 操作
任务切换
INIT 和 SIPI
VM退出，如果“conceal VMX from PT” VM-exit控制位为0（参见第32.5.1节）
VM进入，如果“conceal VMX from PT” VM-entry控制位为0

在SMI和RSM操作中不会生成PIP数据包，即使CR3发生了变化。这是由于这些操作的特殊行为导致的，详见第32.2.9.3节。需要注意的是，在某些不修改CR3的任务切换情况下，不会产生PIP数据包。

PIP的目的是告知解码器正在运行的应用程序，以便它可以将适当的二进制文件应用于正在跟踪的线性地址。

当写入CR3时，PIP数据包包含新的CR3值。

由VM进入生成的PIP数据包会设置NR位。在VMX非根操作中生成的PIP数据包，如果“conceal VMX from PT” VM-execution控制位为0，则设置NR位（参见第32.5.1节）。所有其他的PIP数据包都会清除NR位。

（5）Application：PIP数据包的目的是帮助解码器在任何给定时间内唯一识别正在运行的软件。

当遇到PIP数据包时，解码器应执行以下操作：
1）如果存在先前未绑定的FUP数据包（即，未由消耗它的MODE.TSX等数据包前导的FUP数据包，并且它与尚未看到的TIP数据包配对），则此PIP是复合数据包事件的一部分（第32.4.1节）。查找最后的TIP数据包，并将新的CR3/NR值应用于TIP数据包的有效载荷IP。
2）否则，在反汇编中查找下一个MOV CR3、远程分支或VMRESUME/VMLAUNCH指令，并将新的CR3值应用于下一个（或目标）IP。

有关这些流程生成的数据包示例，请参见第32.7节。

int pt_encode_pip(struct pt_encoder *encoder, uint64_t cr3, uint8_t flags)
{struct pt_packet packet;packet.type = ppt_pip;packet.payload.pip.cr3 = cr3;packet.payload.pip.nr = (flags & pt_pl_pip_nr) != 0;return pt_enc_next(encoder, &packet);
}

2.8 MODE Packets

MODE数据包使解码器了解其需要了解的各种处理器模式，以便正确地管理数据包输出或正确地分解相关联的二进制文件。MODE数据包包括一个标头和一个模式字节，如下所示：
在这里插入图片描述
MODE叶标识（Leaf ID）指示了在较低位中保存的模式位集合。

2.8.1 MODE.Exec Packet

MODE.Exec Packet
（1）Packet Format
在这里插入图片描述
MODE Leaf ID is '000.

（2）Dependencies：TriggerEn && ContextEn && FilterEn

（3）Generation Scenario：
以下情况涉及到操作或事件，可能会改变特定的模式位或控制寄存器：

如果IA32_RTIT_CTL.BranchEn=1，任何改变CS.L、CS.D或EFER.LMA的操作：
当IA32_RTIT_CTL.BranchEn为1且有操作改变CS.L、CS.D或EFER.LMA时，需要跟踪这些变化的模式位信息。解码器应相应地更新并反映这些模式位的新值。
如果IA32_RTIT_CTL.EventEn=1，任何改变RFLAGS.IF的操作：
当IA32_RTIT_CTL.EventEn为1且有操作改变RFLAGS.IF（中断标志位）时，需要监控和跟踪此变化。解码器需要了解RFLAGS.IF的新值，以正确管理模式信息并处理随后的事件或中断。
任何TIP.PGE情况，其中跟踪的任何模式位可能自上次MODE.Exec以来发生了变化：
在TIP.PGE情况下，如果任何跟踪的模式位可能自上次MODE.Exec以来发生了变化，需要注意。解码器需要处理这些变化，确保准确跟踪模式并正确处理随后的指令。

这些情况涉及监测更改特定模式位或控制寄存器的操作或事件。解码器需要跟踪这些变化，以保持对当前模式的准确表示，并确保正确处理随后的指令。

(4) Description：
这些情况涉及到确定软件处于16位、32位或64位模式的方式，通过提供CS.D和(CS.L和IA32_EFER.LMA)的值来完成。这对于解码器正确反汇编相关的二进制代码非常重要。此外，如果CPUID.0x14.0.EBX[6]=1（“事件跟踪支持”），它通过提供RFLAGS.IF的值来指示中断是否被屏蔽。

MODE.Exec数据包在模式更改时发送，如果在该时刻满足依赖条件，否则将在跟踪恢复时发送。在前一种情况下，MODE.Exec数据包与改变模式的操作产生的其他数据包一起生成，并且在分支操作中必定紧随其后是TIP或TIP.PGE，非分支操作中必定紧随其后是FUP（如果EventEn=1，则为CLI、STI或POPF）。在模式更改时过滤依赖条件不满足的情况下，处理器确保解码器不会丢失模式跟踪，一旦跟踪恢复，会发送任何需要的MODE.Exec（如果BranchEn=1，则在TIP.PGE之前）。如果模式与上一个MODE.Exec数据包的模式匹配，处理器在跟踪恢复时可以选择抑制MODE.Exec。

只有在启用了控制流跟踪（BranchEn=1）的情况下，MODE.Exec数据包才会在CS.L、CS.D或EFER.LMA更改时生成。这对于解码器正确反汇编相关的二进制代码非常重要。
在这里插入图片描述
MODE.Exec数据包仅在中断标志(RFLAGS.IF)更改时生成，前提是事件跟踪已启用（EventEn=1）。

（5）Application：
MODE.Exec数据包始终在IP数据包（TIP、TIP.PGE或FUP）之前发送。模式更改应用于IP数据包中负载中的IP地址。当MODE.Exec后跟一个FUP时，它是一个独立的FUP数据包，并应由MODE.Exec数据包处理。

int pt_encode_mode_exec(struct pt_encoder *encoder, enum pt_exec_mode mode)
{struct pt_packet packet;packet.type = ppt_mode;packet.payload.mode.leaf = pt_mol_exec;packet.payload.mode.bits.exec = pt_set_exec_mode(mode);return pt_enc_next(encoder, &packet);
}

2.8.2 MODE.TSX Packet

MODE.TSX Packet
（1）Packet Format：
在这里插入图片描述
（2）Dependencies：TriggerEn && ContextEn

（3）Generation Scenario：XBEGIN、XEND、XABORT、XACQUIRE和XRELEASE是与事务性内存扩展（Transactional Synchronization Extensions，TSX）相关的指令。在TSX事务中，如果InTX（事务内部）状态发生变化，可能会触发异步的TSX中止（Abort）操作。

（4）Description：当一个TSX事务（无论是HLE还是RTM）开始、提交或中止时会发出相应的指示。在事务执行期间执行的指令如果事务中止，将会被“回滚”（rolled back）。
在这里插入图片描述
（5）Application：
如果PacketEn=1（数据包使能位为1），MODE.TSX数据包总是紧随其后即将出现一个FUP数据包。如果TXAbort位为零，则模式更改将应用于FUP数据包负载中的IP地址。如果TXAbort=1，则FUP数据包后面将是一个TIP数据包，并且模式更改将应用于TIP数据包负载中的IP地址。

当PacketEn=0时，由于FilterEn=0，可能会生成MODE.TSX数据包。在这种情况下，只有在TIP.PGE之前生成的最后一个MODE.TSX数据包需要应用。

int pt_encode_mode_tsx(struct pt_encoder *encoder, uint8_t bits)
{struct pt_packet packet;packet.type = ppt_mode;packet.payload.mode.leaf = pt_mol_tsx;if (bits & pt_mob_tsx_intx)packet.payload.mode.bits.tsx.intx = 1;elsepacket.payload.mode.bits.tsx.intx = 0;if (bits & pt_mob_tsx_abrt)packet.payload.mode.bits.tsx.abrt = 1;elsepacket.payload.mode.bits.tsx.abrt = 0;return pt_enc_next(encoder, &packet);
}

2.9 TraceStop Packet

TraceStop Packet
（1）Packet Format：
在这里插入图片描述
（2）Dependencies：TriggerEn && ContextEn

（3）Generation Scenario：
以下情况下会发生MODE.Exec数据包的生成：

在跟踪停止（TraceStop）IP区域内，出现目标为已经采取的分支（Taken branch）。
在跟踪停止（TraceStop）IP区域内，执行了MOV CR3指令。
在跟踪停止（TraceStop）IP区域内，执行了设置了TraceEn的WRMSR指令。

这些操作会导致模式发生变化，因此需要生成MODE.Exec数据包来通知解码器进行相应的处理。MODE.Exec数据包用于跟踪和解码相关的二进制代码。

（4）Description：
当软件进入用户配置的TraceStop区域时，会发出相应的指示。

当IP地址匹配TraceStop范围，并且ContextEn和TriggerEn被设置时，会触发TraceStop操作。TraceStop操作通过设置IA32_RTIT_STATUS.Stopped来禁用跟踪，从而清除TriggerEn，并生成一个TraceStop数据包。

TraceStop操作还会将FilterEn强制设置为0。请注意，TraceStop可能不会强制刷新内部缓冲的数据包，因此在检查输出之前，仍然应通过清除IA32_RTIT_CTL.TraceEn来手动禁用跟踪数据包的生成。

更多详细信息，请参阅第32.2.5.3节。

（5）Application：
如果TraceStop紧随TIP.PGD之后（在下一个TIP.PGE之前），则它可能是由清除PacketEn的指令触发，或者是由于FilterEn为0时执行的某个后续指令触发。在任何情况下，TraceStop可以应用于TIP.PGD的IP地址（如果有的话）。

如果TraceStop紧随TIP.PGE之后（在下一个TIP.PGD之前），则应将其应用于最后已知的IP地址。

int pt_encode_stop(struct pt_encoder *encoder)
{struct pt_packet packet;packet.type = ppt_stop;return pt_enc_next(encoder, &packet);
}

2.10 Core:Bus Ratio (CBR) Packet

Core:Bus Ratio (CBR) Packet
（1）Packet Format：
在这里插入图片描述
（2）Dependencies： TriggerEn

（3）Generation Scenario：在任何频率变化之后，在C状态唤醒时，PSB+，以及在启用跟踪数据包生成之后。

（4）Description：
核心：总线比率（Core:Bus Ratio）表示处理器核心的核心时钟和总线速度之间的比率。它对于相关 wall-clock 时间和周期时间非常有用。

（5）Application：
CBR（Core:Bus Ratio）数据包指示跟踪中发生频率转换的时刻。在某些实现中，当频率转换发生时，软件执行将继续进行；而在其他情况下，频率转换期间软件执行会停止。CBR数据包没有提供精确的IP地址来绑定。

int pt_encode_cbr(struct pt_encoder *encoder, uint8_t cbr)
{struct pt_packet packet;packet.type = ppt_cbr;packet.payload.cbr.ratio = cbr;return pt_enc_next(encoder, &packet);
}