這兩天在Xen中起D0，很開心的遇到了surfaceflinger起不來的問題，
當然，說surfaceflinger起不來是因爲其他起不來的東西我都不認識，
比如SM什麼的。
這是一個很上層的錯誤了，由很底層的問題引起的。。。
於是。。。這大概跨了一整個從Xen到安卓出人的維度
1.一開始系統並不穩定，走兩步就掛了；自然去logcat找錯誤，
不過還好，logcat能出東西了，logcat出的第一個問題是selinux類的問題，
就是訪問權限沒驗過吧？這是一個可以頭痛醫頭腳痛醫腳的問題，找到那行代碼注掉就好
2.系統穩定了，發現surfaceflinger起不來，surfaceflinger起不來自然是GPU的問題，
搞了一下發現是GPU的內核驅動起不來，根據log，我們找到了問題，GPU有三個中斷，
只有兩個有中斷號，第三個不好使
太特麼氣人了
3.找GPU內核驅動的代碼，不斷地加入打印，中斷號沒有，原因有很多，但是由原先可以用，到現在起不來，
肯定是在Xen的虛擬化存在問題，沿着GPU驅動，找到了platform_device結構體，這是個啥結構體呢。。。
就是驅動加載的時候都會用的結構體，根據Linux的設備模型，它描述了一個設備，裏面有這個設備的資源，
中斷號就在它的資源裏
4.查platform_device,發現沒資源，內核加載後讀dtb進內存，會解出內容放device_node，然後platform會從device_node取得
所需的東西，具體在哪兒乾的不知道，但是沿着函數調用過程，發現：
initcall會找到arm_device_init函數，其中的of_platform_populate會遍歷root節點下的child，都調用到of_platform_bus_create,
然後是of_platform_device_create_pdata()->of_device_alloc()->of_irq_to_resource_table()最終到達of_irq_to_resource()，
這是調試的主要發生地，可以選擇根據device_node的name元素打印，也可以全部打印，於是就查到了很多設備都沒有獲得全部的中斷信息
5.糾結了很久，搗鼓了很久，最終發現Xen中對於#interrupt_cell的定義是死的，3
對，就是3
但是實際上設備樹中用了四個，
Xen對於不關注的設備會原樣不動的發到D0中，所以內核按照3讀實際是4的中斷信息。。。尷尬了。。
6.在Xen裏把增加cell的地方多加一句(原3句)，這是Xen自己產生的設備樹裏用interrupt時就會有四個值
增加Xen自己放interrupt信息的空間數組改爲4
最後把Xen模擬設備時定義的值改爲4。
寫於 2018.10.9
