Protection Strategies for Direct Access to Virtualized I/O D

Protection Strategies for Direct Access to Virtualized I/O Devices appeared in USENIX 2008. 该文比较了五种策略的保护程度和性能开销，遗憾的地方就是该文没有指出五种策略的使用场合，大部分不适用于全虚拟化，而适用于协同虚拟化。 The comparison o

Protection Strategies for Direct Access to Virtualized I/O Devices

appeared in USENIX 2008.

该文比较了五种策略的保护程度和性能开销，遗憾的地方就是该文没有指出五种策略的使用场合，大部分不适用于全虚拟化，而适用于协同虚拟化。

The comparison of these five strategies yields several insights. First, all five strategies provide equivalent inter-guest（客户机之间） protection among OS instances. However, the strategies support differing levels of protection within a particular guest (intra-guest客户机内部 protection). For example, the direct-map strategy incurs almost no performance overhead but supports no intra-guest protection. Conversely, the single-use strategy provides the maximum possible intra-guest protection, but it imposes the largest performance penalty（The traditional single-use strategy provides inter-guest protection at the greatest cost, consuming from 6–26% of the CPU）. Second, there is significant opportunity to reuse IOMMU mappings, which can reduce protection overheads. Multiple concurrent I/O operations are able to share the same mappings often enough that there is a noticeable decrease in the overhead of providing protection. Sharing mappings only among concurrent I/O operations provides the same level of intra-guest protection as the single-use strategy but with less overhead. Relaxing this intra-guest protection guarantee by allowing mappings to persist so that they can be reused in future I/O operations can significantly decrease this overhead, allowing the guest to achieve performance levels very close to that of the direct-map strategy while still maintaining some amount of intraguest protection. Finally, the software-based protection strategy performs competitively with several of the better-performing IOMMU-based strategies while maintaining strong inter-guest protection guarantees and enabling

intra-guest protection capabilities.

五种策略

Single-use Mappings：每一次使用之前才映射，使用完毕解除映射

Shared Mappings：the shared-mapping strategy detects when a valid IOMMU mapping to a memory page already exists and reuses that mapping rather than generating a new one. In practical terms, this sharing can happen when an application repeats the same I/O message or when an application sends or receives small I/O messages that reside in the same memory page.

Persistent Mappings：IOMMU mappings can further be reused by allowing them to persist even after all I/O transactions using the mapping have completed. 即一次使用后就一直保留，不解除映射。

Direct Mappings：To allow maximum reuse of IOMMU mappings and to further reduce runtime overhead, it is possible to permanently map the entire physical address space of the guest operating system.

软件方案（很明显不支持完全虚拟化，而且要求VMM知道硬件细节）：见WILLMANN, P., SHAFER, Concurrent direct network access for virtual machine monitors. In Proceedings of the 13th International Symposium on High Performance Computer Architecture (Feb. 2007).

三种I/O访问错误

Three potential memory access violations can occur on every I/O transfer initiated using this DMA architecture:

1. The device driver could create a DMA descriptor with an incorrect address (a “bad-address” fault).

2. The operating system could repurpose the memory referenced by a DMA descriptor, or the device driver could later reuse a valid DMA descriptor without permission (an “invalid-use” fault).

3. The device itself could initiate a DMA transfer to a memory address not referenced by the DMA descriptor (a “bad-device” fault). the last type of violation is only likely to occur as a result of a device failure.

关于Intra－guest的解释：其他四种方式都要在使用之前先映射（OS会检查），所以能避免bad address。但是建立映射之后，Once the first request to create the IOMMU mapping has happened, however, none of the IOMMU-based strategies can prevent a driver from invalidly reusing that same mapping for a subsequent I/O transaction. In these strategies, the driver is responsible for informing the OS when it is done with an IOMMU mapping. Even if the OS was modified to automatically revoke an IOMMU mapping when it detected the completion of a corresponding I/O event, the driver could still invalidly reuse a mapping after the original I/O event finished, but before the OS could intervene to terminate the IOMMU mapping.

IOMMU的性能开销

Platform I/O PT Update IOTLB Update Update & Flush

IBM Calgary IOMMU 673 10207 10887

Intel VT-d IOMMU 991 1217 2213

AMD GART 27 486 579

Table 2: Microbenchmarks examining costs associated with modern translation hardware, in processor cycles.