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.
