Vol. 3C 36-35
INTEL® PROCESSOR TRACE
the trace. This is not an expected scenario. No CYC packets are generated during overflow, even if the cycle
counter wraps.
Note that, if cycle-accurate mode is enabled, the OVF packet will generate a CYC packet. Because the cycle counter
counts during overflows, this CYC packet can provide the duration of the overflow. However, there is a risk that the
cycle counter wrapped during the overflow, which could render this CYC misleading.
36.3.9 Operational
Errors
Errors are detected as a result of packet output configuration problems, which can include output alignment issues,
ToPA reserved bit violations, or overlapping packet output with restricted memory. See “ToPA Errors” in Section
36.2.6.2 for details on ToPA errors, and Section 36.2.6.4 for details on restricted memory errors. Operational
errors are only detected and signaled when TraceEn=1.
When an operational error is detected, tracing is disabled and the error is logged. Specifically,
IA32_RTIT_STATUS.Error is set, which will cause IA32_RTIT_STATUS.TriggerEn to be 0. This will disable genera-
tion of all packets. Some causes of operational errors may lead to packet bytes being dropped.
It should be noted that the timing of error detection may not be predictable. Errors are signaled when the
processor encounters the problematic configuration. This could be as soon as packet generation is enabled but
could also be later when the problematic entry or field needs to be used.
Once an error is signaled, software should disable packet generation by clearing TraceEn, diagnose and fix the error
condition, and clear IA32_RTIT_STATUS.Error. At this point, packet generation can be re-enabled.
36.4
TRACE PACKETS AND DATA TYPES
This section details the data packets generated by Intel Processor Trace. It is useful for developers writing the
interpretation code that will decode the data packets and apply it to the traced source code.
36.4.1
Packet Relationships and Ordering
This section introduces the concept of packet “binding”, which involves determining the IP in a binary disassembly
at which the change indicated by a given packet applies. Some packets have the associated IP as the payload (FUP,
TIP), while for others the decoder need only search for the next instance of a particular instruction (or instructions)
to bind the packet (TNT). However, in many cases, the decoder will need to consider the relationship between
packets, and to use this packet context to determine how to bind the packet.
Section 36.4.2 below provides detailed descriptions of the packets, including how packets bind to IPs in the disas-
sembly, to other packets, or to nothing at all. Many packets listed are simple to bind, because they are generated
in only a few scenarios. Those that require more consideration are typically part of “compound packet events”, such
as interrupts, exceptions, and some instructions, where multiple packets are generated by a single operation
(instruction or event). These compound packet events frequently begin with a FUP to indicate the source address
(if it is not clear from the disassembly), and are concluded by a TIP or TIP.PGD packet that indicates the destination
address (if one is provided). In this scenario, the FUP is said to be “coupled” with the TIP packet.
Other packets could be in between the coupled FUP and TIP packet. Timing packets, such as TSC, MTC, CYC, or
CBR, could arrive at any time, and hence could intercede in a compound packet event. If an operation changes CR3
or the processor’s mode of execution, a state update packet (i.e., PIP or MODE) is generated. The state changes
indicated by these intermediate packets should be applied at the IP of the TIP* packet. A summary of compound
packet events is provided in Table 36-15; see Section 36.4.2 for more per-packet details and Section 36.7 for more
detailed packet generation examples.