1

If I set a SMM breakpoint in firststeps.simics and examine the registers, it shows the expected RIP = 0x8000 and CS base = 0x30000. But if I do the same thing in qsp-client-core.simics, it shows RIP = 0xdffebe74 and CS base = 0, and I don't understand why.

Eventually I see the SMBASE get moved from 0x30000 to 0xdffcd000. But it seems like what the X58 chipset manual says is the TSeg, doesn't get set to that same value, which is what I would expect. Any idea why the TSeg is never set?

simics> print -x %msr_ia32_smbase
0xdffcd000
simics> get-device-offset  board.mb.nb.core_misc.bank.pci_config 0xA8 4
0 (LE)

(Note: I tested this out on platforms up to skylake, and it seems to only behave this way on coffee lake which is what the qsp-client-core.simics defaults to)

OOO
  • 21
  • 3

1 Answers1

1

I just tried firststeps.simics and I can see that smm handler is relocated as well. smm_base is 0x30000 at the first entry but it changes to 0xdffd3000 almost right away:

$ ./simics targets/qsp-x86/qsp-client-core.simics
simics> output-radix 16
simics> board.mb.cpu0.core[0][0]->smm_base
0x30000
simics> continue-seconds 30
simics> board.mb.cpu0.core[0][0]->smm_base
0xdffd3000

You can see that clearly from logs as well:

simics> board.mb.cpu0.core[0][0].log-group -disable MSR
board.mb.cpu0.core[0][0]:
 enabled log groups: "Intermediate code" "Performance hint" "Other" "VMX" "Hardware breakpoints" "Pin change" "FPU" "Exception" "VM-monitor" "MONITOR" "X86 other" "Default_Log_Group"
 disabled log groups: "MSR"
simics> board.mb.cpu0.core[0][0].log-level 2
[board.mb.cpu0.core[0][0]] Changing log level: 1 -> 2
simics> log-setup -time-stamp 
simics> c
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0x83939a 388559012} IA32_FEATURE_CONTROL set to 0x5
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdf353932 388714533} Cache flush (with write-back)
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdf353987 388714952} Cache flush (with write-back)
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdf353932 388781185} Cache flush (with write-back)
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdf353987 388781604} Cache flush (with write-back)
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdf5765f5 389274426} Cache flush (with write-back)
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdf57664a 389274845} Cache flush (with write-back)
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdef5ed20 393668159} Cache flush (with write-back)
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdef5ecf0 393668269} Cache flush (with write-back)
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdffebe6e 397678713} SMI raised
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdffe43a9 397679321} New SMM base: 0xdffd3000
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdefc3471 398242965} SMI raised
[board.mb.cpu0.core[0][0] info] {board.mb.cpu0.core[0][0] 0xdefc3471 403646564} SMI raised

As you can see, first call to SMM handler changes smm_base which is rather typical thing to do.

I don't know about Tseg but hopefully I at least partially answered your question.

Evgenii Iuliugin
  • 71
  • 1