好得很程序员自学网

<tfoot draggable='sEl'></tfoot>

ProtectionStrategiesforDirectAccesstoVirtualizedI/

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.

查看更多关于ProtectionStrategiesforDirectAccesstoVirtualizedI/的详细内容...

  阅读:37次

CopyRight:2016-2025好得很程序员自学网 备案ICP:湘ICP备09009000号-16 http://haodehen.cn
本站资讯不构成任何建议,仅限于个人分享,参考须谨慎!
本网站对有关资料所引致的错误、不确或遗漏,概不负任何法律责任。
本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等)版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时,请及时通知本站,予以删除。

网站内容来源于网络分享,如有侵权发邮箱到:kenbest@126.com,收到邮件我们会即时下线处理。
网站框架支持:HDHCMS   51LA统计 百度统计
Copyright © 2018-2025 「好得很程序员自学网
[ SiteMap ]