Vol. 3C 36-29
INTEL® PROCESSOR TRACE
36.3.1.1 Packet Decoding of RIP versus LIP
FUP, TIP, TIP.PGE, and TIP.PGE packets can contain an instruction pointer (IP) payload. On some processor gener-
ations, this payload will be an effective address (RIP), while on others this will be a linear address (LIP). In the
former case, the payload is the offset from the current CS base address, while in the latter it is the sum of the offset
and the CS base address (Note that in real mode, the CS base address is the value of CS<<4, while in protected
mode the CS base address is the base linear address of the segment indicated by the CS register.). Which IP type
is in use is indicated by enumeration (see
CPUID.(EAX=14H, ECX=0):ECX.LIP[bit 31] in Table 36-11).
For software that executes while the CS base address is 0 (including all software executing in 64-bit mode), the
difference is indistinguishable. A trace decoder must account for cases where the CS base address is not 0 and the
resolved LIP will not be evident in a trace generated on a CPU that enumerates use of RIP. This is likely to cause
problems when attempting to link the trace with the associated binaries.
Note that IP comparison logic, for IP filtering and TraceStop range calculation, is based on the same IP type as
these IP packets. For processors that output RIP, the IP comparison mechanism is also based on RIP, and hence on
those processors RIP values should be written to IA32_RTIT_ADDRn_[AB] MSRs. This can produce differing
behavior if the same trace configuration setting is run on processors reporting different IP types, i.e.
CPUID.(EAX=14H, ECX=0):ECX.LIP[bit 31]. Care should be taken to check CPUID when configuring IP filters.
36.3.1.2 Model Specific Capability Restrictions
Some processor generations impose restrictions that prevent use of LBRs/BTS/BTM/LERs when software has
enabled tracing with Intel Processor Trace. On these processors, when TraceEn is set, updates of LBR, BTS, BTM,
LERs are suspended but the states of the corresponding IA32_DEBUGCTL control fields remained unchanged as if
it were still enabled. When TraceEn is cleared, the LBR array is reset, and LBR/BTS/BTM/LERs updates will resume.
Further, reads of these registers will return 0, and writes will be dropped.
The list of MSRs whose updates/accesses are restricted follows.
•
MSR_LASTBRANCH_x_TO_IP, MSR_LASTBRANCH_x_FROM_IP, MSR_LBR_INFO_x, MSR_LASTBRANCH_TOS
•
MSR_LER_FROM_IP, MSR_LER_TO_IP
•
MSR_LBR_SELECT
For processor with CPUID DisplayFamily_DisplayModel signature of 06_3DH, 06_47H, 06_4EH, 06_4FH, 06_56H
and 06_5EH, the use of Intel PT and LBRs are mutually exclusive.
36.3.2
Enabling and Configuration of Trace Packet Generation
To configure trace packets, enable packet generation, and capture packets, software starts with using CPUID
instruction to detect its feature flag, CPUID.(EAX=07H,ECX=0H):EBX[bit 25] = 1; followed by enumerating the
capabilities described in Section 36.3.1.
Based on the capability queried from Section 36.3.1, software must configure a number of model-specific regis-
ters. This section describes programming considerations related to those MSRs.
36.3.2.1 Enabling Packet Generation
When configuring and enabling packet generation, the IA32_RTIT_CTL MSR should be written after any other Intel
PT MSRs have been written, since writes to the other configuration MSRs cause a general-protection fault (#GP) if
TraceEn = 1. If a prior trace collection context is not being restored, then software should first clear
IA32_RTIT_STATUS. This is important since the Stopped, and Error fields are writable; clearing the MSR clears any
values that may have persisted from prior trace packet collection contexts. See Section 36.2.7.2 for details of
packets generated by setting TraceEn to 1.
If setting TraceEn to 1 causes an operational error (see Section 36.3.9), there may be a delay after the WRMSR
completes before the error is signaled in the IA32_RTIT_STATUS MSR.
While packet generation is enabled, the values of some configuration MSRs (e.g., IA32_RTIT_STATUS and
IA32_RTIT_OUTPUT_*) are transient, and reads may return values that are out of date. Only after packet genera-
tion is disabled (by clearing TraceEn) do reads of these MSRs return reliable values.