这两天在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
