有段時間沒有光顧博客了，年後工作內容飽滿，各種各樣的事情，忙得不亦樂乎。
今天有點時間，就寫一下其中一個bug的解決吧，也算記錄一下一個程序員日常工作的點滴。另外也讓人們看看intel的漏洞給我們程序員帶來多大的麻煩。
這篇文章我想盡量寫的非技術化，我想讓圍牆外的人們也瞭解一下程序員的工作。也許兒子長大了做的是和計算機無關的工作，他看到這篇文章也許會說：‘哦，爸爸每天就是做這些啊，真沒勁’。
都知道intel的補丁會拖累系統的性能，離奇的是最近報的一個bug中顯示OVM3.4打上microcode補丁後啓動時間延長了兩分半，這是客戶不能接受的！
而且這個問題只在公司的幾臺大的服務器上可以重現，本人的兩臺小dell pc就一邊去吧，而這也給解決問題增加了難度。
這個bug早在年前就被客戶提出來了，由於調試環境的缺乏一直懸在那裏。最近借來一臺機器趕緊開整。
對於啓動問題，kdump派不上用場，唯一可以依賴的就是啓動時打印的那段log，可以看到有一段間隔有大概200s的時間。
(XEN) [2018-03-16 04:33:19] Dom0 has maximum 20 VCPUs
(XEN) [2018-03-16 04:33:19] ELF: phdr 0 at 0xffffffff81000000 -> 0xffffffff81ac8 000
(XEN) [2018-03-16 04:33:19] ELF: phdr 1 at 0xffffffff81ac8000 -> 0xffffffff81c53 000
(XEN) [2018-03-16 04:33:19] ELF: phdr 2 at 0xffffffff81c53000 -> 0xffffffff81c6c 318
(XEN) [2018-03-16 04:33:19] ELF: phdr 3 at 0xffffffff81c6d000 -> 0xffffffff81e4e 000
(XEN) [2018-03-16 04:36:42] [VT-D]iommu.c:1555: d0:unknown(0): 0000:7f:0e.2
通過測試發現這段間隔在用舊的XEN跑也得花費50s左右的時間。分析比對代碼發現是construct_dom0這個龐然大物。因爲dom0有11GB之多，構造這麼大的guest花50s也不算多，所以這不是construct_dom0本身的問題。
那是什麼原因呢，繼續看代碼，調試，看代碼。。。。此處略去十萬字。
陽光總在風雨後，工作這麼多年來我發現一個現象，在一個bug調試很久都沒有結果的時候總是會有一個轉機出現。 這次這個轉機來的還算快，就是加上參數“bti=ibrs=0”以後啓動速度正常了。但是這把ibrs的功能都禁掉了，客戶的系統還會暴露在Spectre2的攻擊威脅之下。
還得繼續看代碼，但是只需要看Spectre相關的代碼了，主要是x86彙編中中斷，異常和nmi部分的入口和出口代碼。還真讓我發現了一個代碼的bug，我們用的一個比較指令永遠會跳轉，IBRS不會關掉，而這在若干人若干次的review中居然沒有發現包括我，然後居然被提交了，而且在海量測試中竟沒有觸發panic。
我彷彿看到了一絲曙光，期待着就此修復這個問題，修改後的測試結果給我潑了一盆冷水，問題照舊！
進一步的分析發現啓動階段還是得關掉IBRS，讓啓動代碼跑在全速的環境下。過程不表，加上新的修改後客戶表示happy了。
到此故事還沒有完，
patch發到社區，維護者提了若干意見，還在繼續溝通中。
那邊緊急來電，2.6.18內核Spectre補丁有點問題，請速去救援。。。