这个山头今天好像要攻占下来了
guest os中的一些特权操作会被hypervhisor给接收，这里一个很重要的认识是：hypervisor是os的os，既然要访问资源，那么就需要经过整机资源的管理者vmm决定，以前操作系统是整机资源的管理者，现在是hypervisior了！这是理解整个虚拟化的核心；
好了，我们现在试着理解下virtio虚拟化做了一些神马事情，之前一直没搞明白，是因为以前不知道所谓的virtio的驱动前端和后端到底发生在哪里。是每个驱动都要具备吗？想想不对，这样的话，写驱动就太麻烦了，还要考虑到虚拟化的前后端；如果是访问本地磁盘设备，那么是作用在block层吗？好像也不是很对，hypervisor是接收到一些指令的，但是block层就是个软件，不会有什么特殊的指令在呀，分析到这里，再加上网上的一些资料，我们基本清楚了：问题是发生在驱动真正出发了读外设的指令时！该类指令对于cpu来说都是一些特权指令，因为设备是一种资源不是谁都能随便访问的，所以，这个时候虚机的执行就停止了，一般外设的指令都是有具体的设备号的page地址，然后这些数据都被hypervisor给拿出来了，传递给注册的qume进程，那磁盘读写操作为例，这个时候如果是读磁盘，那么qemu会从宿主机中将数据读上来，然后将数据拷贝到共享内存页，然后通知kvm可以反回了，在这里涉及到多处内存拷贝，数据流是设备上的数据，经过宿主机文件系统--》共享内存页--》guest文件系统
这是传统的纯软件化的方案，那么virtio解决了神马事情呢？老方案有太多的拷贝了，新的方案中，guest文件系统，只需要把相应的文件的page放到virtio设备中，然后同样去通知qemu，这个时候qemu只要去通知驱动的后端去处理virtio 队列中的io事件就可以了，所以减少了很多的内存拷贝，这样一来，就节省了时间了；
【所以说，这种虚拟化到底发生在哪里？其实，都是我们软件出身的人认知以外的事情了，是发生在驱动层！发生在驱动层！发生在整个数据链路的最后一层：比驱动还下面呢】所以我们平常说的block层stap仍然有效，我们用的tcpdump仍然有效！
virtio貌似已经有着接近宿主机的IO性能了，这里相当于在驱动层又做了一层缓存，和block层的缓存、驱动的缓存，本质上并没有多大的差异；