永远选择相信同步原语
起因
qemu有一个可以让虚拟机(guest)使用宿主机(host)的音频播放的参数，-device audio。这个参数在x86上效果不错，但是在arm上效果不行，杂音很多，所以我们需要解决这个问题。方案是使用共享内存ivshmem。
具体的说，就是改写微软的官方样例驱动。虽然这些bug看起来简单，但是由于windows的奇怪特性，以及ARM上没有合适的调试工具，所以我们调试了很久很久......
调试的故事
调试的方法无非是打日志、看coredump、单步调试。
- 打日志
打日志可以用DbgPrint，它的输出可以用过DbgView看到。
DbgView有ARM架构版本的，也有x86版本的。虽然微软确实有x86转ARM指令集的功能，但是DbgView ARM版本异常容易崩溃，只能够用一小段时间，然后就会崩溃......据说qemu有串口输出日志的功能，但是由于我们要使用内核态，所以这个功能难以试出来。
- 看coredump
这个功能在x86上是可用的，在ARM上因为一些奇奇怪怪的问题，我们要用BcdEdit开启。大致只记得开启了测试模式，然后对照x86去修改其他bcd选项，然后又开了其他几个选项，不限制coredump大小，此时才有概率能够产生coredump。好在崩溃问题几乎是必现的，所以最终能够在几次重启之后正常获得coredump。
- 单步调试
据同事说，他曾在x86上用过这个功能对内核态驱动实体机单步调试，但是我们试过很多方法，花了大约两三天，都没有搞定。
最终结论，具体说，要使用单步调试，我们就需要网络，在进入系统前就必须要有网络。但是！我们只能在虚拟机中调试，而虚拟机中的驱动是在系统启动之后才加载，所以我们用不了这种方法。
当然，微软还提供了几个选择，比如可以用串口来单步调试，但是估计串口驱动也可能是在启动之后加载的，再加上在调试过程中我已经找到了崩溃的原因，所以就没有继续研究了。
所以，微软，我xxx
BUG1：缺乏同步原语导致的杂音
这是在录音这一部分遇到的bug。这里说的杂音是说，如果你给他录制人声，你能够听得出是这个人说的话，但是你听不清他说的是什么内容。如下图
也就是说，在真正写入数据之前就已经开始录音了，表现的效果就是听不清在说啥。
而播放是没有这个杂音问题的，也需要画图说明。
也就是说，播放的时候，在本次数据完整交给host播放之前，下一次数据是阻塞等待的。
所以录音有杂音，而播放无杂音，本质上就是同步原语的问题。我们无法修改windows内核的代码，所以没法用类似于播放的方法。
至于为什么非得要一个IO线程，就得看气人的安全措施protection ring：
https://en.wikipedia.org/wiki/Protection_ring
这个ring中，ring2级别的无法访问ring0、1级别的内容。而我们的驱动运行在两个级别中，初始化的时候是0，初始化之后，读取、写入音频数据的时候是2，而在IO线程中是0，而IVSHMEM共享内存的ring级别就是0。
所以摆在我们面前的只有两个方案：
- 在IO队列与驱动之间加一个缓冲区
IO队列将所有能够读到的数据放入缓冲区，然后在windows请求读取的时候，之间从该缓冲区中读取。这样就可以解决这个问题了。
这个方案有几个问题。初始化的时候获取的ring级别是0吗？加入缓冲区导致的延迟可以接受吗？
- 让IVSHMEM可以在ring2级别中读取，规避掉IO线程
这是我们最终的方案，修改qemu的IVSHMEM源代码，让它能够跑在ring2级别中。具体修改的过程，只记得是IVSHMEM明明已经支持了这个功能，但是它没有开放给用户用，所以稍微加一个if-else就搞定了
BUG2：作为同步使用的WorkItem为NULL导致的驱动崩溃
这个bug似乎是和对象构造、析构相关的。它在播放与录音中都出现过，但是特点是：
只在arm上出现，不会在x86上出现
不过由于我们最后规避掉了IO线程，所以这个问题只在播放中出现过。
就是因为这个bug，我们花了大把时间在开启coredump上。coredump的问题已经讨论过了。最后修复它的方案就是分割驱动为一个录音驱动和一个播放驱动。虽然确实可以查出来该问题的根本并修复，但是我们发现用简单的方法处理了之后，在ARM上播放依然有杂音。所以我们当时推测是播放录音有相互干扰，所以分割为两个驱动，到此发现杂音没了。
如果时间够的话，我还真想排查出来WorkItem为什么会被释放。我们时间不够了，必须要赶紧做完这东西。
现在回想起来，说不定是ARM的内存屏障没有x86那么严格。我听说有一个公司将x86的java程序放arm上执行的时候就因为这个出现过毛病。