3.3.2 时间和定时器

    Xen为每个guest OS提供了真实时间，虚拟时间和挂钟时间（wall-clock time）等三个概念。真实时间是以纳秒为单位给出的，是从机器引导起来开始计算的时间，它记录的是精确的处理器执行的时钟周期数，时钟周期能够被外部时钟源锁频（例如，通过NTP时间服务）。domain的虚拟时间只是在它运行的时候才会被记入：这主要供guest OS的调度器使用来确保guest OS上的应用进程能够正确地共享时间片。最后，挂钟时间是一个偏移，用于加到当前的真实时间上。挂钟时间能够被调整（//比如在各个guest OS中的时间可以不同，有的是上午九点，有的是下午三点，改的就是这个值），同时不会影响真实时间的流逝。

    每一个guest OS能够对一对警钟定时器进行编程，一个用于真实时间，另一个用于虚拟时间。guest OS能够维护内部的定时器队列（//很多应用程序都有定时需求，真实的或者虚拟的，特别是网络应用；guest OS要对这些定时需求排队以确定谁的时间要求最紧迫，然后就尽量依次满足它们；只要有一个定时需求没被满足，即超时了，那么系统就产生异常）并使用Xen提供的警钟定时器来触发最早的超时。超时事件将会使用Xen事件机制来递交。

    3.3.3虚拟地址转换

    和其它子系统一样，Xen也努力以尽可能小的开销实现存储访问的虚拟化。正如2.1.1中讨论的，由于x86架构使用的是硬件页表，因此达到这个目标有些难度。VMware中使用的方法是为每个guest OS提供虚拟的页表，这个页表对于存储管理单元（MMU）是不可见的[10].然后由hypervisor负责陷入对虚拟页表的访问，确认更新，再将这些改变传播到虚拟页表和MMU可见的“影子”页表（//“影子”页表在第2部分提到过）。这大大增加了这个guest

    OS操作的代价，比如创建一个新的虚拟地址空间，需要对“访问过的”和“脏的”比特位上的硬件更新进行显式地传播。

    之所以完全虚拟化要强迫使用影子页表，是因为它要给出连续的物理内存的假象，而Xen就不拘泥于此。实际上，Xen只需要考虑对页表的更新，来防止guest OS导致不可接受的改变。因此我们避免了和使用影子页表相关的开销和额外的复杂度 — Xen中的方法是直接地由MMU记录guest OS的页表，并且限制住guest OS只能做读访问。页表更新通过hypercall传递给Xen；更新请求在被采纳以前经过确认，这么做就确保了安全性。

    为了有助于确认，我们给机器的每个页框都建立了一个相关的类型和引用数。一个页框在任何时候都会排它地具有下述的某一个类型：页目录（PD），页表（PT），局部描述符表（LDT），全局描述符表（GDT）。同时，这个页框还可能是可写（RW）的类型。一个guest OS可以为它自己所属的页框创建可读的映射，而不必理会页框的当前类型。一个页框只有在它的引用数为0的时候，才能被安全地重新分配给其它任务使用。这个机制被用于满足系统对安全性一贯的需求；例如，一个domain不能够任意地对页表的某个部分建立可写的映射，如果要这么做的话就必须要求页框同时具有PT和RW类型（//什么情况下是可读的映射？什么情况下又是可写的映射呢？）。

    类型系统还要被用于跟踪那些用于页表的页框中哪些是已经被确认过的（//页框用于页表，即页内容填入页框）。这时，guest OS要指出页框是否被分配用作页表 — 这就需要在页框的类型被定为PD或者PT后（//说明页框是用于页表的），由Xen对页框中的每一项做一次性地确认，直至后来由guest OS发出释放（unpin）的请求（//由guest OS释放页框）。这在改变页表基指针的时候是很有用的，因为它不需要在每一次上下文切换时都对新页表进行确认（//因为现在只确认页框了）。注意，一个页框在被释放并且引用数为0之前是不能够被重新分配给其它任务的，这样就避免了guest OS可能会绕开引用数机制而直接利用释放请求导致的危险。

    为了减少所需的hypercall调用的次数，guest OS能够在利用一个hypercall进行整批处理之前在局部将更新排入一个队列。特别是在创建新的地址空间的时候，这一点是尤其有好处的。但是无论怎样，我们必须确保更新被提交得足够早以保证准确性。幸运的是，一个guest OS在第一次使用一个新的映射前要执行一次TLB刷新：这确保了任何被缓存的改变（//这些改变目前仅存于TLB中，还没有被写入内存页表项）都是没有经过确认的。因此，在TLB刷新之前立即提交那些待处理的更新就可以满足正确性（//更新的时间，解决了什么时候进行成批更新操作以保证正确性的问题）。可是，有一些guest OS会在TLB中没有陈旧表项存在（//没有陈旧表项意味着更新都已经送达内存中？）的时候省略掉这个刷新的步骤。在这种情况下，就有可能发生第一次试图使用新的映射时会发生缺页错误（//因为没有刷新TLB）。 这时，guest OS错误句柄就必须要核查是否需要更新；如果需要的话，TLB就要被刷新（//加入所缺的内容），并且将导致刚才缺页错误的指令重新执行。

    3.3.4物理内存

    为各个domain进行的初始的内存分配，或者说内存保留，都是在domain被创建的时候进行的；因此，内存在domain之间是静态划分的，这就提供了强大的隔离性。最大允许的内存保留量是被规定了的：如果某个domain中的内存压力增加了，那么它就可以从Xen争取额外的内存页，直到达到规定保留量的上限。反过来，如果一个domain希望节省些资源，避免不必要的开销，它也能够通过释放内存页给Xen来减少它的内存保留量。

    XenoLinux实现了一个气球驱动 [42]（//没看相关文献），它能够通过在Xen和XenoLinux的页面分配器之间传递内存页来调整domain的内存使用。虽然我们能够直接修改Linux的内存管理例程，但是气球驱动能够利用现有的操作系统功能来进行调整，因此简化了Linux的移植工作。无论怎样，准虚拟化能够被用于扩展气球驱动的能力。例如，guest OS中的内存越界处理机制能够被修改为通过向Xen请求更多的内存页来自动地减轻内存压力。

    大部分操作系统都假定内存空间是由大量的较大规模的连续区域组成的。由于Xen并不保证它为guest OS分配的内存区域是连续的，所以guest OS需要为它们自己创建连续的物理内存的假象，即使它们实际在底层分配到的硬件内存是稀疏的。guest OS通过简单地维护一个以实际分得的页框号为索引的数组，来完全负责从实际分得的地址（physical）到硬件地址的映射。Xen提供了一个共享的地址转换数组，这个数组用于支持从硬件地址到各个domain实际分得地址的映射，它是所有的domain都可读的 — 更新这个数组是经过Xen确认的，以确保guest OS能够拥有相应的硬件页框。

    即使一个guest OS在大多数情况下选择了忽略硬件地址（//因为guest OS喜欢在连续的地址空间上运行），但是在它访问它所拥有的页表的时候（这时必须使用硬件地址）必须使用转换表。硬件地址也可以暴露给操作系统存储管理系统中的有限的某些部分以优化存储访问（//具体是哪些部分可以直接“看到”硬件地址呢？）。例如，一个guest OS可以分配特定的硬件页用于优化以实际分得地址为索引的缓存中的布局，或者使用超级页将硬件内存中的连续部分作自然对齐的映射。

    3.3.5网络

    Xen提供了虚拟防火墙—路由器（VFR）的抽象，每个domain都有一个或多个在逻辑上附属于VFR的网络接口（VIF）。VIF看上去有些现代的网卡：具有两个I/O缓冲区描述符环，一个用于发送一个用于接收。在每个方向（//发送或者接收）上都有一些相关的规则形式（<模式>，<动作>）— 如果模式（pattern）匹配上的话，那么相关的动作（action）就会被起用。

    Domain 0负责插入和删除规则。例如在典型的情况下，可以增加规则防止源IP地址欺骗，或者增加规则确保基于目的IP地址和端口的正确的数据分派（demultiplexing）。规则也可以是和VFR上的硬件接口相关的。特别是我们增加的那些用于执行传统的防火墙功能的规则，比如防止在不安全的端口上建立连接的企图。

上一页  [1] [2] [3] [4] [5] [6] [7] 下一页