AComparisonofSoftwareandHardwareTechniquesforx86Virtualization资源-CSDN文库

需积分: 10 152 浏览量 2010-05-05 09:58:31 上传评论收藏 153KB PDF 举报

### 软件与硬件技术在x86虚拟化中的比较 #### 摘要本文探讨了软件和硬件技术在x86架构下的虚拟化技术，并对其性能进行了比较分析。作者首先回顾了VMware Workstation等软件虚拟机监控器（VMM）的工作原理，特别是对虚拟指令执行引擎的性能特性进行了深入研究。接着，文中讨论了近年来Intel和AMD等处理器制造商为支持经典虚拟化而引入的新架构扩展，并基于这些硬件支持设计了一种新的硬件VMM。 #### 研究背景与目标传统的x86架构并不支持经典的陷阱与模拟（Trap-and-Emulate）虚拟化技术，因此像VMware Workstation和Virtual PC这样的虚拟机监控器不得不采用二进制翻译技术来完全虚拟化x86系统。随着Intel和AMD分别推出VT-x和SVM等支持虚拟化的硬件扩展，使得经典虚拟化成为可能。本研究的目标是通过量化的方式比较纯软件VMM与硬件支持下的VMM之间的性能差异，并探索导致性能差异的根本原因。 #### 主要发现令人惊讶的是，在许多情况下，硬件VMM的表现并不优于纯软件VMM。为了探究原因，作者研究了一系列架构级别的事件，包括页表更新、上下文切换和输入/输出操作的成本。研究结果表明，硬件支持未能提供明确的性能优势主要有两个原因：第一，它不支持内存管理单元（MMU）的虚拟化；第二，它无法与现有的用于MMU虚拟化的软件技术共存。 #### 讨论 ##### MMU虚拟化的挑战内存管理单元（MMU）的虚拟化对于实现高效和灵活的虚拟化环境至关重要。MMU负责将虚拟地址转换为物理地址，这对于多租户环境来说非常重要，因为它可以确保每个虚拟机的内存空间被正确隔离。然而，目前的硬件扩展并未提供足够的支持来处理MMU虚拟化的需求，这限制了硬件VMM的性能优势。 ##### 性能比较通过对不同类型的虚拟机监控器进行性能测试，可以观察到硬件VMM在某些特定操作上的表现不如软件VMM。例如，上下文切换和I/O操作的开销通常更大，这是由于硬件支持在处理这些任务时缺乏优化或灵活性。此外，页表更新也是一个关键因素，它直接影响到虚拟机的性能和响应时间。 ##### 未来方向文章最后展望了未来可能的解决方案和技术发展，旨在解决MMU虚拟化问题。这些解决方案包括改进的硬件支持、更高效的软件技术以及混合方法，它们能够更好地协同工作以提高整体性能。例如，嵌套分页（Nested Paging）是一种由Intel提出的用于增强MMU虚拟化的方法，它可以减少页表更新的开销，从而改善虚拟机的性能。 ### 结论尽管硬件支持为x86虚拟化带来了新的可能性，但现有的硬件扩展尚未能够全面解决虚拟化过程中的所有挑战，尤其是在MMU虚拟化方面。因此，软件技术仍然是提升虚拟机性能的关键因素之一。未来的研究和发展应继续探索如何优化硬件支持，同时开发更高效的软件策略，以实现更强大的虚拟化能力。

资源推荐

资源详情

资源评论

A Comparison of Software and Hardware Techniques for x86

Virtualization

Keith Adams

VMware

kma@vmware.com

Ole Agesen

VMware

agesen@vmware.com

Until recently, the x86 architecture has not permitted classical

trap-and-emulate virtualization. Virtual Machine Monitors for x86,

such as VMware

R

Workstation and Virtual PC, have instead used

binary translation of the guest kernel code. However, both Intel

and AMD have now introduced architectural extensions to support

classical virtualization.

We compare an existing software VMM with a new VMM de-

signed for the emerging hardware support. Surprisingly, the hard-

ware VMM often suffers lower performance than the pure software

VMM. To determine why, we study architecture-level events such

as page table updates, context switches and I/O, and ﬁnd their costs

vastly different among native, software VMM and hardware VMM

execution.

We ﬁnd that the hardware support fails to provide an unambigu-

ous performance advantage for two primary reasons: ﬁrst, it of-

fers no support for MMU virtualization; second, it fails to co-exist

with existing software techniques for MMU virtualization. We look

ahead to emerging techniques for addressing this MMU virtualiza-

tion problem in the context of hardware-assisted virtualization.

Categories and SubjectDescriptors C.0 [General]: Hardware/soft-

ware interface; C.4 [Performance of systems]: Performance at-

tributes; D.4.7 [Operating Systems]: Organization and design

General Terms Performance, Design

Keywords Virtualization, Virtual Machine Monitor, Dynamic Bi-

nary Translation, x86, VT, SVM, MMU, TLB, Nested Paging

1. Introduction

The x86 has historically lacked hardware support for virtualization

[21]. While paravirtualization [5, 25], or changing the guest operat-

ing system to permit virtualization, has produced promising results,

such changes are not always practical or desirable.

The need to virtualize unmodiﬁed x86 operating systems has

given rise to software techniques that go beyond the classical trap-

and-emulate Virtual Machine Monitor (VMM). The best known of

these software VMMs, VMware Workstation and Virtual PC, use

binary translation to fully virtualize x86. The software VMMs have

enabled widespread use of x86 virtual machines to offer server con-

solidation, fault containment, security and resource management.

Permission to make digital or hard copies of all or part of this work for personal or

classroom use is granted without fee provided that copies are not made or distributed

for proﬁt or commercial advantage and that copies bear this notice and the full citation

on the ﬁrst page. To copy otherwise, to republish, to post on servers or to redistribute

to lists, requires prior speciﬁc permission and/or a fee.

ASPLOS’06

October 21–25, 2006, San Jose, California, USA.

 2006 ACM 1-59593-451-0/06/0010...$5.00

Recently, the major x86 CPU manufacturers have announced ar-

chitectural extensions to directly support virtualization in hardware.

The transition from software-only VMMs to hardware-assisted

VMMs provides an opportunity to examine the strengths and weak-

nesses of both techniques.

The main technical contributions of this paper are (1) a re-

view of VMware Workstation’s software VMM, focusing on per-

formance properties of the virtual instruction execution engine;

(2) a review of the emerging hardware support, identifying perfor-

mance trade-offs; (3) a quantitative performance comparison of a

software and a hardware VMM.

Surprisingly, we ﬁnd that the ﬁrst-generation hardware sup-

port rarely offers performance advantages over existing software

techniques. We ascribe this situation to high VMM/guest transi-

tion costs and a rigid programming model that leaves little room

for software ﬂexibility in managing either the frequency or cost of

these transitions.

While the ﬁrst round of hardware support has been locked down,

future rounds can still be inﬂuenced, and should be guided by

an understanding of the trade-offs between today’s software and

hardware virtualization techniques. We hope our results encour-

age hardware designers to support the proven software techniques

rather than seeking to replace them; we believe the beneﬁts of soft-

ware ﬂexibility to virtual machine performance and functionality

are compelling.

The rest of this paper is organized as follows. In Section 2, we

review classical virtualization techniques and establish terminol-

ogy. Section 3 describes our software VMM. Section 4 summarizes

the hardware enhancements and describes how the software VMM

was modiﬁed to exploit hardware support. Section 5 compares the

two VMMs qualitatively and Section 6 presents experimental re-

sults and explains these in terms of the VMMs’ properties. Section

7 looks ahead to future software and hardware solutions to the key

MMU virtualization problem. Section 8 summarizes related work

and Section 9 concludes.

2. Classical virtualization

Popek and Goldberg’s 1974 paper [19] establishes three essential

characteristics for system software to be considered a VMM:

1. Fidelity. Software on the VMM executes identically to its exe-

cution on hardware, barring timing effects.

2. Performance. An overwhelming majority of guest instructions

are executed by the hardware without the intervention of the

VMM.

3. Safety. The VMM manages all hardware resources.

In 1974, a particular VMM implementation style, trap-and-

emulate, was so prevalent as to be considered the only practical

method for virtualization. Although Popek and Goldberg did not

rule out use of other techniques, some confusion has resulted over

the years from informally equating “virtualizability” with the abil-

ity to use trap-and-emulate.

To side-step this confusion we shall use the term classically vir-

tualizable to describe an architecture that can be virtualized purely

with trap-and-emulate. In this sense, x86 is not classically virtualiz-

able, but it is virtualizable by Popek and Goldberg’s criteria, using

the techniques described in Section 3.

In this section, we review the most important ideas from classi-

cal VMM implementations: de-privileging, shadow structures and

traces. Readers who are already familiar with these concepts may

wish to skip forward to Section 3.

2.1 De-privileging

In a classically virtualizable architecture, all instructions that read

or write privileged state can be made to trap when executed in an

unprivileged context. Sometimes the traps result from the instruc-

tion type itself (e.g., an out instruction), and sometimes the traps

result from the VMM protecting structures that the instructions ac-

cess (e.g., the address range of a memory-mapped I/O device).

A classical VMM executes guest operating systems directly, but

at a reduced privilege level. The VMM intercepts traps from the

de-privileged guest, and emulates the trapping instruction against

the virtual machine state. This technique has been extensively de-

scribed in the literature (e.g., [10, 22, 23]), and it is easily veriﬁed

that the resulting VMM meets the Popek and Goldberg criteria.

2.2 Primary and shadow structures

By deﬁnition, the privileged state of a virtual system differs from

that of the underlying hardware. The VMM’s basic function is to

provide an execution environment that meets the guest’s expecta-

tions in spite of this difference.

To accomplish this, the VMM derives shadow structures from

guest-level primary structures. On-CPU privileged state, such as

the page table pointer register or processor status register, is han-

dled trivially: the VMM maintains an image of the guest register,

and refers to that image in instruction emulation as guest operations

trap.

However, off-CPU privileged data, such as page tables, may re-

side in memory. In this case, guest accesses to the privileged state

may not naturally coincide with trapping instructions. For exam-

ple, guest page table entries (PTEs) are privileged state due to their

encoding of mappings and permissions. Dependencies on this priv-

ileged state are not accompanied by traps: every guest virtual mem-

ory reference depends on the permissions and mappings encoded in

the corresponding PTE.

Such in-memory privileged state can be modiﬁed by any store

in the guest instruction stream, or even implicitly modiﬁed as a

side effect of a DMA I/O operation. Memory-mapped I/O devices

present a similar difﬁculty: reads and writes to this privileged data

can originate from almost any memory operation in the guest in-

struction stream.

2.3 Memory traces

To maintain coherency of shadow structures, VMMs typically

use hardware page protection mechanisms to trap accesses to in-

memory primary structures. For example, guest PTEs for which

shadow PTEs have been constructed may be write-protected.

Memory-mapped devices must generally be protected for both

reading and writing. This page-protection technique is known as

tracing. Classical VMMs handle a trace fault similarly to a privi-

leged instruction fault: by decoding the faulting guest instruction,

emulating its effect in the primary structure, and propagating the

change to the shadow structure.

2.4 Tracing example: x86 page tables

To protect the host from guest memory accesses, VMMs typically

construct shadow page tables in which to run the guest. x86 speci-

ﬁes hierarchical hardware-walked page tables having 2, 3 or 4 lev-

els. The hardware page table pointer is control register %cr3.

VMware Workstation’s VMM manages its shadow page tables

as a cache of the guest page tables. As the guest accesses previously

untouched regions of its virtual address space, hardware page faults

vector control to the VMM. The VMM distinguishes true page

faults, caused by violations of the protection policy encoded in

the guest PTEs, from hidden page faults, caused by misses in the

shadow page table. True faults are forwarded to the guest; hidden

faults cause the VMM to construct an appropriate shadow PTE,

and resume guest execution. The fault is “hidden” because it has

no guest-visible effect.

The VMM uses traces to prevent its shadow PTEs from becom-

ing incoherent with the guest PTEs. The resulting trace faults can

themselves be a source of overhead, and other coherency mecha-

nisms are possible. At the other extreme, avoiding all use of traces

causes either a large number of hidden faults or an expensive con-

text switch to prevalidate shadow page tables for the new context.

In our experience, striking a favorable balance in this three-way

trade-off among trace costs, hidden page faults and context switch

costs is surprising both in its difﬁculty and its criticality to VMM

performance. Tools that make this trade-off more forgiving are rare

and precious.

2.5 Reﬁnements to classical virtualization

The type of workload signiﬁcantly impacts the performance of the

classical virtualization approach [20]. During the ﬁrst virtual ma-

chine boom, it was common for the VMM, the hardware, and all

guest operating systems to be produced by a single company. These

vertically integrated companies enabled researchers and practi-

tioners to reﬁne classical virtualization using two orthogonal ap-

proaches.

One approach exploited ﬂexibility in the VMM/guest OS in-

terface. Implementors taking this approach modiﬁed guest operat-

ing systems to provide higher-level information to the VMM [13].

This approach relaxes Popek and Goldberg’s ﬁdelity requirement

to provide gains in performance, and optionally to provide features

beyond the bare baseline deﬁnition of virtualization, such as con-

trolled VM-to-VM communication.

The other approach for reﬁning classical VMMs exploited ﬂex-

ibility in the hardware/VMM interface. IBM’s System 370 archi-

tecture introduced interpretive execution [17], a hardware execu-

tion mode for running guest operating systems. The VMM encodes

much of the guest privileged state in a hardware-deﬁned format,

then executes the SIE instruction to “start interpretive execution.”

Many guest operations which would trap in a de-privileged environ-

ment directly access shadow ﬁelds in interpretive execution. While

the VMM must still handle some traps, SIE was successful in re-

ducing the frequency of traps relative to an unassisted trap-and-

emulate VMM.

Both of these approaches have intellectual heirs in the present

virtualization boom. The attempt to exploit ﬂexibility in the OS/VMM

layer has been revived under the name paravirtualization [25].

Meanwhile, x86 vendors are introducing hardware facilities in-

spired by interpretive execution; see Section 4.

3. Software virtualization

We review basic obstacles to classical virtualization of the x86

architecture, explain how binary translation (BT) overcomes the

obstacles, and show that adaptive BT improves efﬁciency.

剩余11页未读，继续阅读

评论收藏

内容反馈

zcc0221002

粉丝: 0
资源: 12

A Comparison of Software and Hardware Techniques for x86 Virtual...

最新资源

A Comparison of Software and Hardware Techniques for x86 Virtual...

Hardware and Software Support for Virtualization.pdf

Wiley Publishing.Managing the Testing Process.Practical Tools and Techniques for Managing Hardware and Software Testing.2002

[request_ebook] Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing

A Comparison of Complementary and Kalman Filtering

A Comparison of Antialiasing Techniques 抗锯齿技术的比较

Linux assemblers: A comparison of GAS and NASM

A Comparison of DHMM and DTW for

A Comparison and Evaluation of Multi-View Stereo Reconstruction Algorithms

学习符号序列的LSTM和GRU网络的比较_A comparison of LSTM and GRU networks for l

A Comparison of Document Clustering Techniques 文本挖掘聚类算法

Java vs. Symbian: A Comparison of Software-based DSR

A comparison of 3D file formats.pdf

Comparison of Various Learning Rate Scheduling Techniques on Con

A Comparison of Affine Region Detectors University of Oxford论文

A Comparison of SIFT, PCA-SIFT and SURF.ppt

A comparison of the Kaufman Assessment Battery for Children and the Stanford-Binet IV for the assessment of gifted children

A comparison of urban and rural reliability estimates for the Boehm Basic Concept Test

A Comparison of Dictionary Implementations

A Comparison of Decision Tree, KNN, andXGBoost for Fashion-MNIST

Comparison of modified Morse and Rose equations of state for solids

A Comparison of UL 60950 and GR 1089

An Experimental Comparison of Min-Cut/Max-Flow Algorithms

comparison of academic and informal writing

!A quantitative comparison of change detection algorithms

Local Strict Comparison Theorem and Converse Comparison Theorems for Reflected Backward Stochastic Differential Equations

Synchronization Techniques for OFDMA- A Tutorial Review.pdf

最新资源