Vol. 3C 36-13

INTEL® PROCESSOR TRACE

Intel PT is not frozen on PMI, and thus the interrupt handler will be traced (though filtering can prevent this). The 
Freeze_Perfmon_on_PMI and Freeze_LBRs_on_PMI settings in IA32_DEBUGCTL will be applied on ToPA PMI just as 
on other PMIs, and hence Perfmon counters are frozen.
Assuming the PMI handler wishes to read any buffered packets for persistent output, or wishes to modify any Intel 
PT MSRs, software should first disable packet generation by clearing TraceEn. This ensures that all buffered packets 
are written to memory and avoids tracing of the PMI handler. The configuration MSRs can then be used to deter-
mine where tracing has stopped. If packet generation is disabled by the handler, it should then be manually re-
enabled before the IRET if continued tracing is desired.
In rare cases, it may be possible to trigger a second ToPA PMI before the first is handled. This can happen if another 
ToPA region with INT=1 is filled before, or shortly after, the first PMI is taken, perhaps due to EFLAGS.IF being 
cleared for an extended period of time. This can manifest in two ways: either the second PMI is triggered before the 
first is taken, and hence only one PMI is taken, or the second is triggered after the first is taken, and thus will be 
taken when the handler for the first completes. Software can minimize the likelihood of the second case by clearing 
TraceEn at the beginning of the PMI handler. Further, it can detect such cases by then checking the Interrupt 
Request Register (IRR) for PMI pending, and checking the ToPA table base and off-set pointers (in 
IA32_RTIT_OUTPUT_BASE and IA32_RTIT_OUTPUT_MASK_PTRS) to see if multiple entries with INT=1 have been 
filled.

ToPA PMI and Single Output Region ToPA Implementation

A processor that supports only a single ToPA output region implementation (such that only one output region is 
supported; see above) will attempt to signal a ToPA PMI interrupt before the output wraps and overwrites the top 
of the buffer. To support this functionality, the PMI handler should disable packet generation as soon as possible.
Due to PMI skid, it is possible that, in rare cases, the wrap will have occurred before the PMI is delivered. Software 
can avoid this by setting the STOP bit in the ToPA entry (see Table 36-3); this will disable tracing once the region is 
filled, and no wrap will occur. This approach has the downside of disabling packet generation so that some of the 
instructions that led up to the PMI will not be traced. If the PMI skid is significant enough to cause the region to fill 
and tracing to be disabled, the PMI handler will need to clear the IA32_RTIT_STATUS.Stopped indication before 
tracing can resume.

ToPA PMI and XSAVES/XRSTORS State Handling

In some cases the ToPA PMI may be taken after completion of an XSAVES instruction that switches Intel PT state, 
and in such cases any modification of Intel PT MSRs within the PMI handler will not persist when the saved Intel PT 
context is later restored with XRSTORS. To account for such a scenario, it is recommended that the Intel PT output 
configuration be modified by altering the ToPA tables themselves, rather than the Intel PT output MSRs. 
Table 36-4 depicts a recommended PMI handler algorithm for managing multi-region ToPA output and handling 
ToPA PMIs that may arrive between XSAVES and XRSTORS. This algorithm is flexible to allow software to choose 
between adding entries to the current ToPA table, adding a new ToPA table, or using the current ToPA table as a 
circular buffer. It assumes that the ToPA entry that triggers the PMI is not the last entry in the table, which is the 
recommended treatment.