XenBus是通过XenStore协商的一套协议，前端和后端通过XenBus进行协商最终建立起通信， 前端和后端都是状态机，而状态转换的条件就是由XenBus来完成的，本篇将介绍XenBus. 源码可以从Github上得到。

Xen的PV Driver使用的是Split Model, 到这里现在也比较清楚前后端的交互方式了，通过Grant Table来共享I/O ring, 在ring中放入所需数据的grant reference, 并通过Event Channel机制来告知对方，而初始的grant reference则通过XenStore来进行共享。

在上一篇中我们了解了XenStore的作用和交互方式，本篇将实现一个最简单的PV Split Driver, 并通过向XenStore中写入相应的配置信息来激活驱动。 而在下一篇中我将加入XenBus的状态信息。

XenStore是由Dom0维护的分层的存储系统(像一个小文件系统目录一样), 用于在Guest之间共享信息，通过Shared Memory来进行 数据共享。利用XenStore, Guest之间可以交流外设信息、Dom0可以读取到其他Guest的配置信息。

Hypervisor自身不会意识到XenStore的存在，XenStore的地址也是通过Shared_info page在Guest启动时进行map. 也因此Hypervisor中没有任何关于XenStore的Hypercall. 但是XenStore却是Xen中非常重要的一部分. 本篇将简单介绍XenStore和其使用。(用的是Linux 4.10.2)

前一篇我们已经了解了Event Channel是如何被注册和被Hypervisor实现的，本篇将利用kernel module，使用Event Channel进行Guest间的通信。

PV, HVM, PV-on-HVM, PVHVM, PVH… Xen在刚提出的时候针对的是二进制模拟下的虚拟化低效问题, 而随着Intel与AMD不断推出支持虚拟化的硬件后，使用PV已经不再是一个最恰当的选择。而如今，Xen 已经有了眼花缭乱的各种模式，本文将介绍他们之间的区别。

I/O Ring能够让我们通过共享内存传输数据，但是在准备好数据后又该如何告知远端的Dom呢？因此类似中断，这里就要用到Event_Channel来进行异步通知。Event Channel是Xen提供的一套 等价于硬件中断的通信机制，其融合了Physical Interrupt, Virtual Interrupt和Inter/Intradomain Communication.

本篇博文分为两部分，这篇介绍Event Channel的实现机制，另一篇介绍Event Channel如何在Guest中使用。

说到年终总结怎能没有ACG的总结，和工作睡觉一样占据我生活近三分之一的娱乐(除运动和社交)活动当然也要总结一下啦~ 去年的感觉过于冗长和啰嗦.. 今年就挑重点的来说吧，好看的说说个人感想，不好看的就当个排雷~

17年的新番已蓄势待发，16年的动画也都全部完结…依旧是长文不过无图放心戳=v=

追番带有带有极强的个人主观意见，不喜轻喷~

2016 是历史魔幻元年，历史的涡轮发动机推着人文社会这辆高铁飞驰— 2016一年就见证了太多的大事…

2016 是相对比较充实的一年，好好工作，为毕业而奋斗… 因为去年是刚建这个blog没多久进行的总结，所以非常仓促，今年的总结其实每个月都有在进行，现在写出来也方便自己以后来比较和反省。

在上一篇中我们通过Grant Table让DomU和Dom0能够通过内存共享进行通信，众所周知在Xen里domU的I/O都是交由dom0来完成的。而I/O driver也有两种实现方式: paravirtualized和qemu-emulated。本篇主要讨论Xen上PV Driver所使用的数据结构: I/O Device Ring。

本来觉得这个挺简单，不过发现每次写都会忘，这次就把常用的关于Kernel Module的操作和命令放一起做个小的总结吧~