http___en.wikipedia.org_wiki_Hardware-assisted_virtualization.xml
1.1 2.1 2.2 2.3 2.4 2.5 3.1 4.1 5.1 6.1 7.1 8.1 9.1 10.1 11.1 12.1 12.2 12.3 13.1 14.1 15.1 16.1 17.1 18.1 19.1 19.2 20.1 20.2 20.3 20.4 20.5 21.1 22.1 23.1 24.1 25.1 26.1 27.1 28.1 29.1 30.1 30.2 31.1 31.2 31.3 31.4 32.1 33.1 33.2 34.1 34.2 35.1 36.1 37.1 37.2 37.3 37.4 37.5 37.6 38.1 39.1 39.2 40.1 40.2 40.3 40.4 41.1 42.1 43.1 44.1 44.2 45.1 46.1 47.1 48.1 49.1 50.1 51.1 52.1 53.1 54.1 54.2 55.1 56.1 56.2 57.1 59.1 60.1 61.1 62.1 64.1 65.1 66.1 67.1 68.1 69.1 70.1 71.1 72.1 73.1 74.1 74.2 75.1 76.1 76.2 76.3 76.4 76.5 76.6 76.7 77.1 77.2 77.3 78.1 79.1 81.1 81.2 82.1 83.1 84.1 85.1 86.1 87.1 87.2 87.3 87.4 87.5 88.1 89.1 89.2 90.1 90.2 91.1 91.2 91.3 91.4 92.1 92.2 92.3 92.4 93.1 93.2 93.3 93.4 94.1 94.2 94.3 95.1 95.2 95.3 96.1 97.1 98.1 99.1 100.1 100.2 100.3 101.1 101.2 101.3 102.1 102.2 102.3
Изисквания за виртуализация на Попек и Голдбърг Изискванията за виртуализация на Попек и Голдбърг са набор от условия, достатъчни за компютърна архитектура, която да поддържа ефективно системна виртуализация. Те са въведени от Gerald J. Popek и Robert P. Goldberg в тяхна статия от 1974 Формални изисквания за виртуализация на трето поколение архитектури.[1] . Въпреки, че тези изисквания са получени чрез опростени предположения, те все още представляват удобен начин за определяне дали дадена компютърна архитектура поддържа ефективна виртуализация и да предоставят насоки за проектиране на виртуализирани компютърни архитектури. Съдържание - 1 Дефиниция на монитор на виртуална машина - хипервайзор (VMM, hypervisor) - 2 Теореми за виртуализация - 3 Обработка на критичните инструкции - 4 Набор от инструкции за общи архитектури - 5 Производителността на практика - 6 Вижте също - 7 Източници Дефиниция на монитор на виртуална машина - хипервайзор (VMM, hypervisor)[редактиране | редактиране на кода] Системните виртуални машини могат да виртуализират пълен набор от хардуерни ресурси, включително процесор (или процесори), ресурси за памет и съхранение и периферни устройста. Мониторът (VMM, наречен също hypervisor) е част от софтуера, който осигурява абстракция на виртуална машина. Съществуват три важни свойства на среда, създадена от VMM: [2] - Еквивалентност/Вярност - Програма, работеща под контрола на VMM, трябва да показва поведение идентично по същество с това, демонстрирано, когато работи директно на еквивалентна машина. - Контрол на ресурсите/Безопасност - VMM трябва да има пълен контрол върху виртуализираните ресурси. - Ефективност / Изпълнение - Статистически доминиращата част от машинните инструкции трябва да бъдат изпълнени без намесата на VMM. В терминологията на Popek и Goldberg, една VMM трябва да има и трите свойства. В терминологията, използвана в справочника на Smith и Nair (2005), VMM обикновено се приемат, като отговарящи на свойствата за еквивалентност и контрол на ресурсите, а тези, които допълнително отговарят и на свойството за изпълнение се наричат ефективни VMMs.[3] Popek и Goldberg описват характеристиките, които набора от инструкции (Instruction Set Architecture - ISA) на физическата машина трябва да притежава, за да задвижи VMM, със горните три свойства. Техният анализ извлича такива характеристики с помощта на модел на архитектури от трето поколение (например, IBM 360, Honeywell 6000, DEC PDP-10), който е все пак достатъчно общ, за да бъде разширен до съвременни машини. Този модел включва процесор, който работи или в системен или потребителски режим, и има достъп до линейна, постоянно адресируема памет. Предполага се, че подгрупа на набора от инструкции е достъпна само, когато е в системен режим и че паметта се адресира относително в зависимост от регистър на преместванията. I/O и прекъсванията не са моделирани. Теореми за виртуализация[редактиране | редактиране на кода] За да извлекат своите виртуализационни теореми, които дават достатъчни (а не необходими) условия за виртуализация, Popek и Goldberg въвеждат класификация на инструкциите на ISA в три различни групи: - Привилегировани инструкции - тези, които прекъсват (trap), ако процесорът е в потребителски режим (user mode) и не прекъсват, ако е в системен режим (supervisor mode). - Инструкции, чувствителни към контрола - Тези, които се опитват да променят конфигурацията на ресурсите в системата. - Инструкции, чувствителни към поведението - Тези, чието поведение или резултат зависи от конфигурацията на ресурсите (съдържанието на регистър за преместването или режима на процесора). Основният резултат от анализа на Popek и Goldberg може да бъде изразен, както следва: Теорема 1. За всеки конвенционален компютър от трето поколение (third-generation computer), ефективен VMM може да се конструира, ако наборът от чувствителни инструкции за този компютър е подгрупа на набора от привилегировани инструкции. Интуитивно, теоремата гласи, че, за да се изгради VMM, е достатъчно всички инструкции, които могат да засегнат правилното функциониране на VMM (чувствителни инструкции), винаги прекъсват и предават контрола към VMM. Това гарантира свойството за ресурсен контрол. Непривилегированите инструкции трябва вместо това да се изпълнят нативно (т.е. ефективно). Запазването на свойството за еквивалентност също следва от това. Тази теорема също осигурява проста техника за създаване на VMM, наречена trap-and-emulate виртуализация, от скоро наричана класическа виртуализация: защото всички чувствителни инструкции работят добре, всичко, което VMM трябва да направи, е да прихваща и емулира всяка една от тях.[4] Свързан с това проблем е, че се извличат достатъчни условия за рекурсивна виртуализация, което означава, че може да се създадат условия, под които може да се стартира VMM, така че да работи върху копие на себе си. Popek и Goldberg представят следните (достатъчни) условия: Теорема 2. Обикновен компютър от трето поколение (third-generation computer) може да се виртуализира рекурсивно, ако - е възможен за виртуализация и - може да се създаде VMM за него без никакви времеви зависимости. Някои архитектури като тези без хардуерна помощ x86 не отговарят на тези условия, така че те не могат да бъдат виртуализирани по класическия начин. Но архитектурите все още може да бъдат напълно виртуализирани (в x86 случая - CPU и MMU нивата) чрез използване на различни техники като двоичен превод, който заменя чувствителните инструкции, които не генерират прекъсвания [4] , които понякога се наричат решаващи инструкции. Това допълнително обработване, обаче, прави VMM по-малко ефективна на теория. [5], но също така и хардуернитe капани имат значителни разходи по изпълнението.. Една добре настроена кешираща система за двоичен превод може да достигне сравнима производителност и го прави в случая на x86 двоичен превод спрямо първото поколение на x86 хардуерна помощ, което просто направи чувствителните инструкции (лесни за прихващане)trappable. [6] Ефективно, това дава една теорема с различни условия по достатъчността . Обработка на критичните инструкции[редактиране | редактиране на кода] Условията за виртуализация, изразени в теорема 1, могат да бъдат намалени за сметка на ефективността. Изградени са VMM за невиртуализиращ набор от инструкции (ISA) (в смисъла на Popek и Goldberg). Виртуализацията на такива архитектури изисква правилна обработка на „критичните инструкции”, т.е. чувствителни, но непривилегировани инструкции. Един подход, известен като "пачване" (patching), усвоява техники, обикновено използвани в динамичното прекомпилиране (dynamic recompilation) : критичните инструкции са открити по време на изпълнение и се прекъсват във VMM. Предложени са различни механизми като кеширане на кода за емулация или виртуализация с помощта на хардуер (hardware assists), за да направят процеса на „пачване” по-ефективен. Един различен подход е този на паравиртуализацията (paravirtualization), който изисква да се модифицират („пренесат”) гост-операционните системи преди да заработят във виртуалната среда. Набор от инструкции за общи архитектури[редактиране | редактиране на кода] Разделът представя няколко съответни архитектури и как те се отнасят към изискванията за виртуализация. PDP-10[редактиране | редактиране на кода] PDP-10 архитектурата има няколко инструкции, които са чувствителни (променят или заявяват режима на процесора), но не и привилегировани. .[7] Тези инструкции съхраняват или възстановяват кода, съдържащ USER или IOT битове. - JSR: jump to subroutine - JSP: jump and save program counter - PUSHJ: push down and jump - JRST: jump and restore System/370[редактиране | редактиране на кода] Всички чувствителни инструкции в System/370 са привилегировани: отговарят на изискванията за виртуализация.[8] Motorola MC68000[редактиране | редактиране на кода] Motorola MC68000 има само една непривилегирована чувствителна инструкция: - MOVE from SR Тази инструкция е чувствителна, защото дава достъп до целия статус регистър, който включва не само условен код (condition codes), но и потребител/супервайзор бит, ниво на прекъсване и контрол на средата. В по-късните членове на фамилията, като започнем от MC68010, инструкцията MOVE from SR е направена привилегирована и съществува нова инструкция MOVE from CCR, която дава достъп единствено до регистъра на условния код. IA-32 (x86)[редактиране | редактиране на кода] Наборът от IA-32 инструкции на процесора Pentium съдържа 17 чувствителни, непривилегировани инструкции. Те могат да се разделят в две групи: Чувствителни регистрови инструкции: четене или изменяне на чувствителни регистри и/или места на памет като часови регистър или регистър на прекъсванията: - SGDT, SIDT, SLDT - SMSW - PUSHF, POPF Инструкции за системата за защита: отнасят се към система за защита на съхранението и системата за преместване на памет или адрес: - LAR, LSL, VERR, VERW - POP - PUSH - CALL, JMP, INT n, RET - STR - MOV Въвеждането на наборите от инструкции AMD-V и Intel VT-x през 2005 позволи на х86 процесорите да отговорят на изискванията за виртуализация на Popek и Goldberg IA-64[редактиране | редактиране на кода] Усилията, необходими за поддръжка на виртуализацията върху архитектурата IA-64, са описани в статия от 2000г. от Magenheimer и Christian. SPARC[редактиране | редактиране на кода] „Хиперпривилегирован” режим за архитектурата UltraSPARC е посочен в „UltraSPARC Architecture 2005” [13]. Дефинира се платформата sun4v [14] , която е надмножество на платформата sun4u, но е съвместима със спецификацията SPARC v9 Level-1[15]. Производителността на практика[редактиране | редактиране на кода] Изискването за eфективност в дефиницията на Popek и Goldberg за VMM се отнася единствено до изпълнението на непривилегировани инструкции, които трябва да се изпълнят нативно. Това отличава един VMM от по-общ клас софтуер за емулация на хардуера (emulation). За съжаление, дори и в архитектура, която отговаря на изискванията на Popek и Goldberg, производителността на виртуалната машина може да се различава съществено от реалния хардуер. Ранните експерименти, извършени на System/370 (която отговаря на формалните изисквания на Теорема 1), показват, че производителността на виртуалната машина може да падне до 21% от производителността на нативната машина по някои показатели. Цената за прекъсване и емулиране на привилегированите инструкции във VMM може да бъде значителна. Това накара инженерите на IBM да въведат редица помощен хардуер (hardware assists), което почти удвои производителността на виртуалните машини System/370 [16] Помощният хардуер се е добавял на няколко етапа. Накрая е имало над 100 помощни устройства на последните модели System/370. Един от основните движещи фактори за развитие на помощния хардуер за System/370 беше самата виртуална памет. Когато гостът беше операционна система, която сама по себе си имплементира виртуална памет, дори непривилегированите инструкции можеха да имат по-дълго време за изпълнение – санкция, наложена от изискването за достъп до таблици за преобразуване, което не се използва при нативното изпълнение. (виж shadow page tables).[18] Вижте също[редактиране | редактиране на кода] Източници[редактиране | редактиране на кода] This citation will be automatically completed in the next few minutes. You can jump the queue or expand by hand - ↑ Rogier Dittner, David Rule, The best damn server virtualization book period, Syngress, 2007, ISBN 1-59749-217-5, p. 19 - ↑ Smith and Nair, p. 387 - ↑ а б Adams and Agesen, 2006, pp. 2-3 - ↑ Smith and Nair, p. 391 - ↑ Adams and Agesen, p. 1 and 5 - ↑ S. Galley. PDP-10 Virtual machines. // Proc. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems. 1969, 30–34 с. с. 30–34. - ↑ Smith and Nair, p. 395 - ↑ M68000 8-/16-32-Bit Microprocessor User's Manual, Ninth Edition. Phoenix, AZ, USA, Motorola, Inc., 1993. - ↑ Motorola M68000 Family Programmer's Reference Manual. Phoenix, AZ, USA, Motorola, Inc., 1992. - ↑ John Scott Robin and Cynthia E. Irvine. Analysis of the Intel Pentium's Ability to Support a Secure Virtual Machine Monitor. // Proc. 9th USENIX Security Symposium. 2000. - ↑ Daniel J. Magenheimer and Thomas W. Christian. vBlades: Optimized Paravirtualization for the Itanium Processor Family. // Proc. 3rd Virtual Machine Research & Technology Symposium. - ↑ Weaver, David. UltraSPARC Architecture 2005: One Architecture.... Multiple Innovative Implementations (DraftD0.9). Santa Clara, CA, USA, Sun Microsystems, Inc., 2007-05-17. - ↑ Sun Microsystems, Inc.. UltraSPARC Virtual Machine Specification. Santa Clara, CA, USA, 2006-01-24. - ↑ Weaver, David L. и др. The SPARC Architecture Manual: Version 9. San Jose, CA, USA, SPARC International, Inc., 1994. - ↑ Smith and Nair, p. 415-416 and 426 - ↑ Gum, p. 535 - ↑ Gum, p. 533 - Забележки - Smith, Jim и др. Virtual Machines. Morgan Kaufmann, 2005. - Adams, Keith и др. A Comparison of Software and Hardware Techniques for x86 Virtualization. // Proceedings of the International Conference on Architectural Support for Programming Languages and Operating Systems, San Jose, CA, USA, 2006. 2006-21-2006. Gum, System/370 Extended Architecture: Facilities for Virtual Machines, IBM J. Res. Develop., Vol. 27, No. 6, Nov. 1983, pp. 530–544
1.1 2.1 2.2 2.3 3.1 4.1 5.1 5.2 6.1 6.2 7.1 7.2 7.3 7.4 8.1 9.1 10.1 11.1 12.1 12.2 13.1 14.1 15.1 15.2 15.3 15.4 15.5 16.1 16.2 17.1 18.1 19.1 20.1 21.1 21.2 21.3 22.1 23.1 24.1 25.1 26.1 27.1 28.1 29.1 30.1 31.1 32.1 33.1 34.1 35.1 36.1 37.1 38.1 38.2 38.3 39.1 40.1 41.1 42.1 43.1 43.2 44.1 45.1 45.2 45.3 46.1 46.2 46.3 46.4 47.1 47.2 47.3 48.1 48.2 48.3 48.4 49.1 50.1 50.2 51.1 51.2
Hardware-assisted virtualization In computing, hardware-assisted virtualization is a platform virtualization approach that enables efficient full virtualization using help from hardware capabilities, primarily from the host processors. Full virtualization is used to simulate a complete hardware environment, or virtual machine, in which an unmodified guest operating system (using the same instruction set as the host machine) executes in complete isolation. Hardware-assisted virtualization was added to x86 processors (Intel VT-x or AMD-V) in 2006. Hardware-assisted virtualization is also known as accelerated virtualization; Xen calls it hardware virtual machine (HVM), and Virtual Iron calls it native virtualization. History[edit] Hardware-assisted virtualization first appeared on the IBM System/370 in 1972, for use with VM/370, the first virtual-machine operating system. With the increasing demand for high-definition computer graphics (e.g. CAD), virtualization of mainframes lost some attention in the late 1970s, when the upcoming minicomputers fostered resource allocation through distributed computing, encompassing the commoditization of microcomputers. IBM offer hardware virtualization for their POWER CPUs under AIX (e.g. System p) and for their IBM-Mainframes System z. IBM refers to their specific form of hardware virtualization as "logical partition", or more commonly as LPAR. The increase in compute capacity per x86 server and in particular the substantial increase in modern networks' bandwidths rekindled interest in data-center based computing which is based on virtualization techniques. The primary driver was the potential for server consolidation: virtualization allowed a single server to cost-efficiently consolidate compute power on multiple underutilized dedicated servers. Cloud computing as the new synonym for the said data center based computing (or mainframe-like computing, respectively) through high bandwidth networks is the most visible hallmark of a return to the roots of computing. It is closely connected to virtualization. The initial implementation x86 architecture did not meet the Popek and Goldberg virtualization requirements to achieve "classical virtualization": - equivalence: a program running under the virtual machine monitor (VMM) should exhibit a behavior essentially identical to that demonstrated when running on an equivalent machine directly - resource control (also called safety): the VMM must be in complete control of the virtualized resources - efficiency: a statistically dominant fraction of machine instructions must be executed without VMM intervention This made it difficult to implement a virtual machine monitor for this type of processor. Specific limitations included the inability to trap on some privileged instructions.[1] To compensate for these architectural limitations, designers have accomplished virtualization of the x86 architecture through two methods: full virtualization or paravirtualization.[2] Both create the illusion of physical hardware to achieve the goal of operating system independence from the hardware but present some trade-offs in performance and complexity. - Paravirtualization is a technique in which the hypervisor provides an API and the OS of the guest virtual machine calls that API, requiring OS modifications. - Full virtualization was implemented in first-generation x86 VMMs. It relies on binary translation to trap and virtualize the execution of certain sensitive, non-virtualizable instructions. With this approach, critical instructions are discovered (statically or dynamically at run-time) and replaced with traps into the VMM to be emulated in software. Binary translation can incur a large performance overhead in comparison to a virtual machine running on natively virtualized architectures such as the IBM System/370. VirtualBox, VMware Workstation (for 32-bit guests only), and Microsoft Virtual PC, are well-known commercial implementations of full virtualization. In 2005 and 2006, Intel and AMD (working independently) created new processor extensions to the x86 architecture called Intel VT-x and AMD-V, respectively (On the Itanium architecture, hardware-assisted virtualization is known as VT-i). The first generation of x86 processors to support these extensions were released in late 2005 early 2006: - On November 13, 2005, Intel released two models of Pentium 4 (Model 662 and 672) as the first Intel processors to support VT-x. - On May 23, 2006, AMD released the Athlon 64 ("Orleans"), the Athlon 64 X2 ("Windsor") and the Athlon 64 FX ("Windsor") as the first AMD processors to support this technology. Well-known implementations of hardware-assisted x86 virtualization include VMware Workstation (for 64-bit guests only), Xen 3.x (including derivatives like Virtual Iron), Linux KVM and Microsoft Hyper-V. Pros[edit] Hardware-assisted virtualization reduces the maintenance overhead of paravirtualization as it reduces (ideally, eliminates) the changes needed in the guest operating system. It is also considerably easier to obtain better performance. A practical benefit of hardware-assisted virtualization has been cited by VMware engineers[3] and Virtual Iron. Cons[edit] Hardware-assisted virtualization requires explicit support in the host CPU, which is not available on all x86/x86_64 processors. A "pure" hardware-assisted virtualization approach, using entirely unmodified guest operating systems, involves many VM traps, and thus high CPU overheads, limiting scalability and the efficiency of server consolidation.[4] This performance hit can be mitigated by the use of paravirtualized drivers; the combination has been called "hybrid virtualization".[5] In 2006 first-generation 32- and 64-bit x86 hardware support was found rarely to offer performance advantages over software virtualization.[6] See also[edit] - Further refinements of hardware-assisted virtualization are possible using an IOMMU; this allows native-speed access to dedicated hardware from a guest operating system, including DMA-capable hardware - Rapid Virtualization Indexing - Extended Page Table - Other virtualization techniques include operating system-level virtualization, as practiced by Parallels Virtuozzo Containers, and application virtualization. - Nanokernel - Hardware emulation - Emulator - Joint Test Action Group - Background Debug Mode interface - In-circuit emulator References[edit] - ^ Adams, Keith. "A Comparison of Software and Hardware Techniques for x86 Virtualization". Retrieved 20 January 2013. - ^ Chris Barclay, New approach to virtualizing x86s, Network World, 10/20/2006 - ^ See http://x86vmm.blogspot.com/2005/12/graphics-and-io-virtualization.html - ^ See http://www.valinux.co.jp/documents/tech/presentlib/2007/2007xenconf/Intel.pdf - ^ Jun Nakajima and Asit K. Mallick, Hybrid-Virtualization—Enhanced Virtualization for Linux, in Proceedings of the Linux Symposium, Ottawa, June 2007, http://ols.108.redhat.com/2007/Reprints/nakajima-Reprint.pdf - ^ A Comparison of Software and Hardware Techniques for x86 Virtualization, Keith Adams and Ole Agesen, VMware, ASPLOS’06 October 21–25, 2006, San Jose, California, USA"Surprisingly, we find that the first-generation hardware support rarely offers performance advantages over existing software techniques. We ascribe this situation to high VMM/guest transition costs and a rigid programming model that leaves little room for software flexibility in managing either the frequency or cost of these transitions. Further reading[edit] - Fisher-Ogden, John. "Hardware Support for Efficient Virtualization" (PDF). UCSD. - Smith, Jim; Nair, Ravi (2005). Virtual Machines. Morgan Kaufmann. 8.5 : Performance Enhancement of System Virtual Machines. - Osisek, D. L.; Jackson, K. M.; Gum, P. H. (1991). "ESA/390 interpretive-execution architecture, foundation for VM/ESA" (PDF). IBM Systems Journal 30 (1). - Adams, Keith; Agesen, Ole (2006-21-2006). "A Comparison of Software and Hardware Techniques for x86 Virtualization" (PDF). International Conference on Architectural Support for Programming Languages and Operating Systems, San Jose, CA, USA, 2006. Check date values in: |date=(help) - "Performance Evaluation of AMD RVI Hardware Assist" (PDF). VMware. - "Performance Evaluation of Intel EPT Hardware Assist" (PDF). VMware.