The Intel Trace Hub (aka. North Peak, NPK) is a trace aggregator for
Software, Firmware, and Hardware. On the virtualization platform, it
can be used to output the traces from SOS/UOS/Hypervisor/FW together
with unified timestamps.
There are 2 software visible MMIO space in the npk pci device. One is
the CSR which maps the configuration registers, and the other is the
STMR which is organized as many Masters, and used to send the traces.
Each Master has a fixed number of Channels, which is 128 on GP. Each
channel occupies 64B, so the offset of each Master is 8K (64B*128).
Here is the detailed layout of STMR:
M=NPK_SW_MSTR_STP (1024 on GP)
+-------------------+
| m[M],c[C-1] |
Base(M,C-1) +-------------------+
| ... |
+-------------------+
| m[M],c[0] |
Base(M,0) +-------------------+
| ... |
+-------------------+
| m[i+1],c[1] |
Base(i+1,1) +-------------------+
| m[i+1],c[0] |
Base(i+1,0) +-------------------+
| ... |
+-------------------+
| m[i],c[1] |
Base(i,1)=SW_BAR+0x40 +-------------------+
| m[i],c[0] | 64B
Base(i,0)=SW_BAR +-------------------+
i=NPK_SW_MSTR_STRT (256 on GP)
CSR and STMR are treated differently in npk virtualization because:
1. CSR configuration should come from just one OS, instead of each OS.
In our case, it should come from SOS.
2. For performance and timing concern, the traces from each OS should
be written to STMR directly.
Based on these, the npk virtualization is implemented in this way:
1. The physical CSR is owned by SOS, and dm/npk emulates a software
one for the UOS, to keep the npk driver on UOS unchanged. Some CSR
initial values are configured to make the UOS npk driver think it
is working on a real npk. The CSR configuration from UOS is ignored
by dm, and it will not bring any side-effect. Because traces are the
only things needed from UOS, the location to send traces to and the
trace format are not affected by the CSR configuration.
2. Part of the physical STMR will be reserved for the SOS, and the
others will be passed through to the UOS, so that the UOS can write
the traces to the MMIO space directly.
A parameter is needed to indicate the offset and size of the Masters
to pass through to the UOS. For example, "-s 0:2,npk,512/256", there
are 256 Masters from #768 (256+512, #256 is the starting Master for
software tracing) passed through to the UOS.
CSR STMR
SOS: +--------------+ +----------------------------------+
| physical CSR | | Reserved for SOS | |
+--------------+ +----------------------------------+
UOS: +--------------+ +---------------+
| sw CSR by dm | | mapped to UOS |
+--------------+ +---------------+
Here is an overall flow about how it works.
1. System boots up, and the npk driver on SOS is loaded.
2. The dm is launched with parameters to enable npk virtualization.
3. The dm/npk sets up a bar for CSR, and some values are initialized
based on the parameters, for example, the total number of Masters for
the UOS.
4. The dm/npk sets up a bar for STMR, and maps part of the physical
STMR to it with an offset, according to the parameters.
5. The UOS boots up, and the native npk driver on the UOS is loaded.
6. Enable the traces from UOS, and the traces are written directly to
STMR, but not output by npk for now.
7. Enable the npk output on SOS, and now the traces are output by npk
to the selected target.
8. If the memory is the selected target, the traces can be retrieved
from memory on SOS, after stopping the traces.
Signed-off-by: Zhi Jin <zhi.jin@intel.com>
Reviewed-by: Zhang Di <di.zhang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Zhi Jin