情况1：在host冷重启启动过程中，在soc侧设置系统盘的size，进不去系统，卡住了。

观察发现在soc侧设置完size后，再读发现实际size没有设置下去，还是fpga默认size大小。因为是在host重启过程中配置size没有配置下去，所以就怀疑是和复位有关系，这块host复位影响了配置接口正常工作。排查代码后发现，确实是复位把写寄存器的使能给清除掉了。

情况2：冷重启过程中，有概率卡在option rom加载virtio blk驱动这步

通过统计发现，pcie tlp模块数据写请求使能一直拉高，sop/eop个数仅为2个，一看这个写请求异常了，和pcie对接的是engine_mux合并模块，这个模块统计输出的写请求也是一直拉高的，然后接着排查它的下一级模块，virtio_net，virtio_blk，csr寄存器通道，这几个模块的写请求数量都是正常的，没有说一直增长。那基本就是engine_mux模块出了问题。

因为冷重启过程一般都是有复位操作，那下一步怀疑的方向就是带流复位引起的。

接着在环境复现的时候印证了我的想法，发现在重启的过程中，csr寄存器通道会抛出一个配置中断的请求给到engine_mux模块，导致模块处理出现异常。那么问题来了，为什么重启过程中寄存器会发出配置中断请求？经过排查发现，重启时候soc会配置系统盘size，硬件收到后，会发出一个配置中断。正常来说，现在驱动都还没加载，不能随便发中断。排查代码发现这里做的比较傻瓜，soc这边配置一下，fpga就自动组装配置中断给host。后面加了个配置中断的过滤，就暂时规避了这个问题。后续暂时没出现问题。

情况3：冷重启过程中，有概率进入系统后卡住，卡住原因有时候是virtio_net的control q协商卡住，有时候是virtio_blk后端有IO没回。

通过定位，Virtio_blk的IO卡住现象原因不固定，有时候是获取av idx时候读回来的是0，有时候是获取描述符的时候，解析host的操作出错，有时候是virtio_blk多收到了一些io，导致处理出错。

后面一步一步排查排查到寄存器这块，发现有些q的avail base地址，还有desc base地址有重叠的，还有q vector号也不是顺序的，基本上就解释的通获取idx和获取描述符出错的问题了。那么为啥会出错呢，后面根据抓信号排查初始化流程，发现加载驱动的时候，net/blk是并行加载的，也就是说配置那些base地址的时候net/blk是交叉配置的，出现了这么一种情况，先配置了net的queue select，紧接着来了一个blk的base地址写请求，那么这笔blk的配置地址写请求拿到的是net的queue select，所以这次配置就出错了。后面修改分了blk/net两个queue select，同时加载的时候就不会出现queue select拿错的情况了。后面这个问题就没再出了。

至于重启起来后，virtio_blk模块多收到了一些IO，是因为上一次强制重启时候，fpga内部有些飞行的IO堵在了soc_virtio_net模块里，重启起来后，反压释放，就送到了virtio_blk里了，blk收到这些多余的IO，处理就乱了。后面根据驱动的device status状态，过滤了这部分多余的IO，后面就没出现类似这样问题。