https___en.wikipedia.org_wiki_Popek_and_Goldberg_virtualization_requirements_1.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)[редактиране | edit source] Системните виртуални машини могат да виртуализират пълен набор от хардуерни ресурси, включително процесор (или процесори), ресурси за памет и съхранение и периферни устройста. Мониторът (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 и прекъсванията не са моделирани. Теореми за виртуализация[редактиране | edit source] За да извлекат своите виртуализационни теореми, които дават достатъчни (а не необходими) условия за виртуализация, 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] Ефективно, това дава една теорема с различни условия по достатъчността . Обработка на критичните инструкции[редактиране | edit source] Условията за виртуализация, изразени в теорема 1, могат да бъдат намалени за сметка на ефективността. Изградени са VMM за невиртуализиращ набор от инструкции (ISA) (в смисъла на Popek и Goldberg). Виртуализацията на такива архитектури изисква правилна обработка на „критичните инструкции”, т.е. чувствителни, но непривилегировани инструкции. Един подход, известен като "пачване" (patching), усвоява техники, обикновено използвани в динамичното прекомпилиране (dynamic recompilation) : критичните инструкции са открити по време на изпълнение и се прекъсват във VMM. Предложени са различни механизми като кеширане на кода за емулация или виртуализация с помощта на хардуер (hardware assists), за да направят процеса на „пачване” по-ефективен. Един различен подход е този на паравиртуализацията (paravirtualization), който изисква да се модифицират („пренесат”) гост-операционните системи преди да заработят във виртуалната среда. Набор от инструкции за общи архитектури[редактиране | edit source] Разделът представя няколко съответни архитектури и как те се отнасят към изискванията за виртуализация. PDP-10[редактиране | edit source] 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[редактиране | edit source] Всички чувствителни инструкции в System/370 са привилегировани: отговарят на изискванията за виртуализация.[8] Motorola MC68000[редактиране | edit source] Motorola MC68000 има само една непривилегирована чувствителна инструкция: - MOVE from SR Тази инструкция е чувствителна, защото дава достъп до целия статус регистър, който включва не само условен код (condition codes), но и потребител/супервайзор бит, ниво на прекъсване и контрол на средата. В по-късните членове на фамилията, като започнем от MC68010, инструкцията MOVE from SR е направена привилегирована и съществува нова инструкция MOVE from CCR, която дава достъп единствено до регистъра на условния код. IA-32 (x86)[редактиране | edit source] Наборът от 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[редактиране | edit source] Усилията, необходими за поддръжка на виртуализацията върху архитектурата IA-64, са описани в статия от 2000г. от Magenheimer и Christian. SPARC[редактиране | edit source] „Хиперпривилегирован” режим за архитектурата UltraSPARC е посочен в „UltraSPARC Architecture 2005” [13]. Дефинира се платформата sun4v [14] , която е надмножество на платформата sun4u, но е съвместима със спецификацията SPARC v9 Level-1[15]. Производителността на практика[редактиране | edit source] Изискването за 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] Вижте също[редактиране | edit source] Източници[редактиране | edit source] 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 3.1 4.1 5.1 5.2 5.3 6.1 7.1 8.1 9.1 10.1 11.1 12.1 12.2 13.1 13.2 13.3 13.4 13.5 14.1 15.1 16.1 17.1 18.1 19.1 20.1 21.1 22.1 23.1 23.2 24.1 24.2 24.3 24.4 25.1 26.1 26.2 27.1 27.2 28.1 29.1 30.1 30.2 30.3 31.1 31.2 32.1 33.1 33.2 34.1 34.2 34.3 34.4 35.1 36.1 37.1 38.1 39.1 40.1 41.1 42.1 43.1 44.1 45.1 46.1 47.1 48.1 48.2 50.1 51.1 52.1 53.1 54.1 55.1 56.1 57.1 58.1 59.1 60.1 61.1 62.1 64.1 65.1 66.1 67.1 68.1 69.1 70.1 70.2 70.3 70.4 70.5 70.6 70.7 71.1 71.2 72.1 73.1 73.2 73.3 74.1 75.1 76.1 77.1 78.1 79.1 79.2 79.3 79.4 80.1 81.1 81.2 82.1 82.2 83.1 83.2 83.3 83.4 84.1 84.2 84.3 84.4 84.5 85.1 85.2 85.3 86.1 86.2 86.3 87.1 87.2 87.3 88.1 89.1 90.1 93.1 94.1 94.2 94.3 95.1 95.2 95.3 96.1 96.2
Popek and Goldberg virtualization requirements The Popek and Goldberg virtualization requirements are a set of conditions sufficient for a computer architecture to support system virtualization efficiently. They were introduced by Gerald J. Popek and Robert P. Goldberg in their 1974 article "Formal Requirements for Virtualizable Third Generation Architectures".[1] Even though the requirements are derived under simplifying assumptions, they still represent a convenient way of determining whether a computer architecture supports efficient virtualization and provide guidelines for the design of virtualized computer architectures. Contents VMM definition[edit] System virtual machines are capable of virtualizing a full set of hardware resources, including a processor (or processors), memory and storage resources and peripheral devices. A virtual machine monitor (VMM, also called hypervisor) is the piece of software that provides the abstraction of a virtual machine. There are three properties of interest when analyzing the environment created by a VMM:[2] - Equivalence / Fidelity - A program running under the VMM should exhibit a behavior essentially identical to that demonstrated when running on an equivalent machine directly. - Resource control / Safety - The VMM must be in complete control of the virtualized resources. - Efficiency / Performance - A statistically dominant fraction of machine instructions must be executed without VMM intervention. In the terminology of Popek and Goldberg, a VMM must present all three properties. In the terminology used in the reference book of Smith and Nair (2005), VMMs are typically assumed to satisfy the equivalence and resource control properties, and those additionally meeting the performance property are called efficient VMMs.[3] Popek and Goldberg describe the characteristics that the instruction set architecture (ISA) of the physical machine must possess in order to run VMMs which possess the above properties. Their analysis derives such characteristics using a model of "third generation architectures" (e.g., IBM 360, Honeywell 6000, DEC PDP-10) that is nevertheless general enough to be extended to modern machines. This model includes a processor that operates in either system or user mode, and has access to linear, uniformly addressable memory. It is assumed that a subset of the instruction set is available only when in system mode and that memory is addressed relative to a relocation register. I/O and interrupts are not modelled. Virtualization theorems[edit] To derive their virtualization theorems, which give sufficient (but not necessary) conditions for virtualization, Popek and Goldberg introduce a classification of instructions of an ISA into 3 different groups: - Privileged instructions - Those that trap if the processor is in user mode and do not trap if it is in system mode (supervisor mode). - Control sensitive instructions - Those that attempt to change the configuration of resources in the system. - Behavior sensitive instructions - Those whose behavior or result depends on the configuration of resources (the content of the relocation register or the processor's mode). The main result of Popek and Goldberg's analysis can then be expressed as follows. Theorem 1. For any conventional third-generation computer, an effective VMM may be constructed if the set of sensitive instructions for that computer is a subset of the set of privileged instructions. Intuitively, the theorem states that to build a VMM it is sufficient that all instructions that could affect the correct functioning of the VMM (sensitive instructions) always trap and pass control to the VMM. This guarantees the resource control property. Non-privileged instructions must instead be executed natively (i.e., efficiently). The holding of the equivalence property also follows. This theorem also provides a simple technique for implementing a VMM, called trap-and-emulate virtualization, more recently called classic virtualization: because all sensitive instructions behave nicely, all the VMM has to do is trap and emulate every one of them.[4][5] A related problem is that of deriving sufficient conditions for recursive virtualization, that is, the conditions under which a VMM that can run on a copy of itself can be built. Popek and Goldberg present the following (sufficient) conditions. Theorem 2. A conventional third-generation computer is recursively virtualizable if: - it is virtualizable and - a VMM without any timing dependencies can be constructed for it. Some architectures, like the non-hardware-assisted x86, do not meet these conditions, so they cannot be virtualized in the classic way. But architectures can still be fully virtualized (in the x86 case meaning at the CPU and MMU level) by using different techniques like binary translation, which replaces the sensitive instructions that do not generate traps,[4] which are sometimes called critical instructions. This additional processing however makes the VMM less efficient in theory,[5] but hardware traps have non-negligible performance cost as well.[citation needed] A well-tuned caching binary translation system may achieve comparable performance, and it does in the case of x86 binary translation relative to first generation x86 hardware assist, which merely made sensitive instructions trappable.[6] Effectively this gives a theorem with different sufficiency conditions.[citation needed] Theorem 3. A hybrid VMM may be constructed for any third generation machine in which the set of user sensitive instructions are a subset of the set of privileged instructions: Handling critical instructions[edit] The conditions for ISA virtualization expressed in Theorem 1 may be relaxed at the expense of the efficiency property. VMMs for non-virtualizable ISAs (in the Popek and Goldberg's sense) have routinely been built. The virtualization of such architectures requires correct handling of critical instructions, i.e., sensitive but unprivileged instructions. One approach, known as patching, adopts techniques commonly used in dynamic recompilation: critical instructions are discovered at run-time and replaced with a trap into the VMM. Various mechanisms, such as the caching of emulation code or hardware assists, have been proposed to make the patching process more efficient. A different approach is that of paravirtualization, which requires guest operating systems to be modified (ported) before running in the virtual environment. Instruction sets of common architectures[edit] This section presents some relevant architectures and how they relate to the virtualization requirements. PDP-10[edit] The PDP-10 architecture has a few instructions which are sensitive (alter or query the processor's mode) but not privileged.[7] These instructions save or restore the condition codes containing USER or IOT bits: - JSR: jump to subroutine - JSP: jump and save program counter - PUSHJ: push down and jump - JRST: jump and restore System/370[edit] All sensitive instructions in the System/370 are privileged: it satisfies the virtualization requirements.[8] Motorola MC68000[edit] The Motorola MC68000 has a single unprivileged sensitive instruction: - MOVE from SR This instruction is sensitive because it allows access to the entire status register, which includes not only the condition codes but also the user/supervisor bit, interrupt level, and trace control. In most later family members, starting with the MC68010, the MOVE from SR instruction was made privileged, and a new MOVE from CCR instruction was provided to allow access to the condition code register only.[9] [10] The IA-32 instruction set of the Pentium processor contains 18 sensitive, unprivileged instructions.[11] They can be categorized in two groups: - Sensitive register instructions: read or change sensitive registers or memory locations such as a clock register or interrupt registers: - SGDT, SIDT, SLDT - SMSW - PUSHF, POPF - Protection system instructions: reference the storage protection system, memory or address relocation system: - LAR, LSL, VERR, VERW - POP - PUSH - CALL FAR, JMP FAR, INT n, RETF - STR - MOV (segment registers) The introduction of the AMD-V and Intel VT-x instruction sets in 2005 allows x86 processors to meet the Popek and Goldberg virtualization requirements. The effort needed to support virtualization on the IA-64 architecture is described in a 2000 article by Magenheimer and Christian.[12] SPARC[edit] A "hyperprivileged" mode for the UltraSPARC architecture was specified in UltraSPARC Architecture 2005.'[13] It defines a sun4v platform[14] which is a super-set of the sun4u platform, but is still compliant to the SPARC v9 Level-1[15] specification. PowerPC[edit] All sensitive instructions in the PowerPC instruction set are privileged.[16][17] Performance in practice[edit] The efficiency requirement in Popek and Goldberg's definition of a VMM concerns only the execution of non-privileged instructions, which must execute natively. This is what distinguishes a VMM from the more general class of hardware emulation software. Unfortunately, even on an architecture that meets Popek and Goldberg's requirements, the performance of a virtual machine can differ significantly from the actual hardware. Early experiments performed on the System/370 (which meets the formal requirements of Theorem 1) showed that performance of a virtual machine could be as low as 21% of the native machine in some benchmarks. The cost of trapping and emulating privileged instructions in the VMM can be significant. This led the IBM engineers to introduce a number of hardware assists, which roughly doubled the performance of the System/370 virtual machines.[18] Assists were added in several stages. In the end, there were over 100 assists on the late models System/370.[19] One of the main driving factors for the development of hardware assists for the System/370 was virtual memory itself. When the guest was an operating system that itself implemented virtual memory, even non-privileged instructions could experience longer execution times - a penalty imposed by the requirement to access translation tables not used in native execution (see shadow page tables).[20] References[edit] - ^ Popek, G. J.; Goldberg, R. P. (July 1974). "Formal requirements for virtualizable third generation architectures". Communications of the ACM. - ^ 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 - ^ a b Adams and Agesen, 2006, pp. 2-3 - ^ a b Smith and Nair, p. 391 - ^ Adams and Agesen, p. 1 and 5 - ^ S. W. Galley (1969). "PDP-10 Virtual machines". Proc. ACM SIGARCH-SIGOPS Workshop on Virtual Computer Systems. - ^ 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 (2000). "Analysis of the Intel Pentium's Ability to Support a Secure Virtual Machine Monitor". Proc. 9th USENIX Security Symposium. - ^ Daniel J. Magenheimer and Thomas W. Christian (2000). "vBlades: Optimized Paravirtualization for the Itanium Processor Family". Proc. 3rd Virtual Machine Research & Technology Symposium. USENIX. UltraSPARC Architecture 2005: One Architecture.... Multiple Innovative Implementations (DraftD0.9) (PDF). Santa Clara, CA, USA: Sun Microsystems, Inc. - ^ Sun Microsystems, Inc. (2006-01-24). UltraSPARC Virtual Machine Specification (PDF). Santa Clara, CA, USA. - ^ Weaver, David L.; Tom Germond (1994). The SPARC Architecture Manual: Version 9 (PDF). San Jose, CA, USA: SPARC International, Inc. ISBN 0-13-825001-4. - ^ http://www.pagetable.com/?p=15 - ^ http://www.cs.cmu.edu/~410-s07/lectures/L38_Virtualization.pdf - ^ Smith and Nair, p. 415-416 and 426 - Notes - Smith, James; Ravi Nair (2005). Virtual Machines. Morgan Kaufmann. - Adams, Keith; Agesen, Ole (October 21–25, 2006). "A Comparison of Software and Hardware Techniques for x86 Virtualization" (PDF). Proceedings of the International Conference on Architectural Support for Programming Languages and Operating Systems, San Jose, CA, USA, 2006. - P. H. Gum, System/370 Extended Architecture: Facilities for Virtual Machines, IBM J. Res. Develop., Vol.