Блог

Если я установлю точку SMM останова firststeps.simics и проверю регистры, она покажет ожидаемое RIP = 0x8000 и CS base = 0x30000 . Но если я сделаю то же самое qsp-client-core.simics , это покажет RIP = 0xdffebe74 и CS base = 0 , и я не понимаю, почему.

В конце концов я вижу SMBASE , как переходят от 0x30000 к 0xdffcd000 . Но , похоже, то, что говорится в руководстве по чипсету X58 TSeg , не устанавливается на то же значение, которое я ожидал бы. Есть идеи, почему TSeg это никогда не устанавливается?

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

(Примечание: я протестировал это на платформах до skylake, и, похоже, это происходит только на coffee lake, что по qsp-client-core.simics умолчанию)

Я только что попробовал firststeps.simics и вижу, что обработчик smm также перемещен. smm_base находится 0x30000 на первой записи, но 0xdffd3000 почти сразу меняется на:

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

Вы также можете ясно видеть это из журналов:

 simicsgt; 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" simicsgt; board.mb.cpu0.core[0][0].log-level 2 [board.mb.cpu0.core[0][0]] Changing log level: 1 -gt; 2 simicsgt; log-setup -time-stamp  simicsgt; 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  

Как вы можете видеть, первый вызов обработчика SMM изменяет smm_base, что довольно типично.

Я не знаю, Tseg но, надеюсь, я хотя бы частично ответил на ваш вопрос.