前言
之前我已经完成了最简单的定制，就是添加自定义开发板，模拟开发板LED控制。但是我一直没有搞明白的就是glib的fd管道到底有什么用?通过分析调试底层io控制LED显示到模拟界面这一路感觉都没有用到glib的fd。因为我之认为这个fd就是虚拟io触发的，结果不是。后来通过看qemu自带的说明文档multiple-iothreads.txt，了解到了glib相关的AioContext主要是如下四个功能，模拟时间，模拟中断的下半部，交互信号的事件通知，linux主机文件操作。而我的stm32没有文件系统，又是模拟io电平，没有中断及交互信号，代码中也没有os没有用到timer。怪不得感觉和glib的fd没有关系呢！关于timer我找到了stm32f2xx_timer.cs->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, stm32f2xx_timer_interrupt, s);
关于kvm
那么我上次的LED io相关的仿真模拟，主要用到了kvm，这个被我遗忘了很久的很重要的内容。我又专门做了些了解。其实我之前的io这些回调函数的产生，都是因为kvm起作用了，但是我没有实际操作主机的共享硬件io，所以我理解只用到了kvm的vcpu，至少需要vcpu去处理stm32的elf代码，然后触发io回调函数，最后再设置SDL事件进行显示。
qemu通过调用kvm提供的一系列接口来启动kvm. qemu的入口为vl.c中的main函数, main函数通过调用kvm_init 和 machine->init来初始化kvm. 其中, machine->init会创建vcpu, 用一个线程去模拟vcpu, 该线程执行的函数为qemu_kvm_cpu_thread_fn, 并且该线程最终调用kvm_cpu_exec, 该函数调用kvm_vcpu_ioctl切换到kvm中,下次从kvm中返回时,会接着执行kvm_vcpu_ioctl之后的代码,判断exit_reason,然后进行相应处理。int kvm_cpu_exec(CPUState *cpu) --> run_ret = kvm_vcpu_ioctl(cpu, KVM_RUN, 0);当Guest VM进行IO操作需要访问设备时,就会触发VM Exit 返回到vmx_vcpu_run, vmx保存好vmcs并且记录下VM_EXIT_REASON后返回到调用该函数。
在了解kvm的过程中，就是通过kvm截取目标代码中的io操作，然后交付给qemu进行仿真。
接着还看到了virtio设备，它统一挂载在virtio总线上，这个设计倒是挺好的。由于虚化设备多种多样，为了共享设计，所以就有了virtio设备规范，但是qemu使用virtio设备需要主机支持virtio驱动。
总结
探索发现，乐趣无穷。学以致用，乐趣无穷。创造发明，乐趣无穷。对于我来说，保持学习的状态是一种习惯。
