在完全虚拟化环境下需要仿真现有的硬件设备，而Xen不同于此。Xen给出了一套清楚、简单的设备抽象。这就使得我们能够设计一个接口以有效地满足我们对保护性和隔离性的需求。为了做到这一点，I/O和各个domain之间的数据传递都是要经过Xen的，可以使用的方法有共享内存，异步缓冲区描述符环等。这些方法能够在Xen有效地执行确认检查（例如，检查缓冲区是否包括在了domain的存储空间内）的同时，为在系统中的竖直方向上传递缓冲区信息提供了一个高性能的通信机制。和硬件中断类似，Xen支持一个轻量级的事件递交机制用于为一个domain传送异步通告（notification）。这些通告是在对未决事件类型的位图进行更新的时候产生的，也可以通过调用一个guest OS专有的事件句柄产生。这些调用的返回可以由guest OS来决定是否进行“拖延”处理。例如，这么做（//拖延处理）可以避免在频繁唤醒通告时带来的额外开销。
2.2移植OS到Xen的代价
当前我们的NetBSD移植还处于非常初级的阶段，因此我们就没有将其结果在这里报告。虽然XP的移植要更进一步，但也还处于移植过程中；当前移植的XP能够执行RAM上的用户空间的应用，但是缺乏虚拟的I/O驱动。基于这个原因，表中就没有给出和XP的虚拟设备驱动相关的数据。无论怎样，和Linux一样，我们可以想见这些驱动应该是小的和简单的，因为这要得益于Xen提供的理想的硬件抽象。
衡量代价的标准是与原先的x86代码相比修改或增加的那些必要的注释以及遵从一定格式的代码的行数（不包括设备驱动）。对Windows XP中体系结构无关（architecture independent）的代码所作的改动达到了一个惊人的数字，这是因为Windows XP使用了多种多样的结构和联合来访问页表项（PTE）。每次对页表的访问都不得不被单独地进行修改（//因为每次访问都可能用到不同的结构），当然这个过程是可以采用一些脚本来自动完成的。与此相反的，Linux需要的改动就少了很多，这是因为Linux的存储系统是使用预处理程序中的宏来访问PTE的— 这些宏定义为增加准虚拟化所需的转换和hypervisor调用提供了便利的位置（//就在这些位置上加即可）。
在这两个操作系统中，体系结构特有（architecture specific）的部分用于将x86代码向我们的准虚拟架构的移植。这包括重写那些使用了特权指令的程序，删除大量的低层的系统初始化代码。另外，Window XP需要有更多的改变，这主要是因为之前遗留下来的16位仿真代码的存在以及需要一个略有不同引导加载（boot-loading）机制。注意，XP中的x86特有的代码要比Linux多很多，因此可以预见到在做移植的时候也就需要做更多的工作。
；QQ联络：1360095750。