Editing X86 virtualization (section)

== {{Anchor|SWBASED}}Software-based virtualization ==
The following discussion focuses only on virtualization of the x86 architecture [[protected mode]].

In protected mode the operating system kernel runs at a higher privilege such as [[Protection ring|ring]] 0, and applications at a lower privilege such as ring 3.{{Citation needed|date=January 2019}} In software-based virtualization, a host OS has direct access to hardware while the guest OSs have limited access to hardware, just like any other application of the host OS. One approach used in x86 software-based virtualization to overcome this limitation is called ''ring deprivileging'', which involves running the guest OS at a ring higher (lesser privileged) than 0.<ref>{{cite web |url=http://software.intel.com/sites/default/files/m/0/2/1/b/b/1024-Virtualization.pdf |title=Intel Virtualization Technology Processor Virtualization Extensions and Intel Trusted execution Technology |publisher=Intel.com |date=2007 |access-date=2016-12-12 |url-status=live |archive-url=https://web.archive.org/web/20150521014611/https://software.intel.com/sites/default/files/m/0/2/1/b/b/1024-Virtualization.pdf |archive-date=2015-05-21}}</ref>

Three techniques made virtualization of protected mode possible:
* [[Binary translation]] is used to rewrite certain ring 0 instructions in terms of ring 3 instructions, such as [[Interrupt flag#Setting and clearing|POPF]], that would otherwise fail silently or behave differently when executed above ring 0,<ref>{{cite web |url=http://www.usenix.org/events/sec2000/robin.html |title=USENIX Technical Program - Abstract - Security Symposium - 2000 |publisher=Usenix.org |date=2002-01-29 |access-date=2010-05-02 |url-status=live |archive-url=https://web.archive.org/web/20100610064709/http://www.usenix.org/events/sec2000/robin.html |archive-date=2010-06-10}}</ref><ref name=asplos/>{{rp|3}} making the classic [[Hardware-assisted virtualization|trap-and-emulate virtualization]] impossible.<ref name="asplos">{{cite web |title=A Comparison of Software and Hardware Techniques for x86 Virtualization |url=http://www.vmware.com/pdf/asplos235_adams.pdf |publisher=VMware |access-date=8 September 2010 |url-status=live |archive-url=https://web.archive.org/web/20100820201944/http://www.vmware.com/pdf/asplos235_adams.pdf |archive-date=20 August 2010}}</ref>{{rp|1}}<ref name=pat242>{{US patent|6397242}}</ref> To improve performance, the translated [[basic block]]s need to be cached in a coherent way that detects [[code patching]] (used in [[VxD]]s for instance), the reuse of pages by the guest OS, or even [[self-modifying code]].<ref>{{US patent|6704925}}</ref>
* A number of key data structures used by a processor need to be [[Shadow memory|shadowed]]. Because most operating systems use [[paged virtual memory]], and granting the guest OS direct access to the [[memory management unit|MMU]] would mean loss of control by the [[hypervisor|virtualization manager]], some of the work of the x86 MMU needs to be duplicated in software for the guest OS using a technique known as ''shadow page tables''.<ref>{{cite web |url=http://www.vmware.com/pdf/virtualization_considerations.pdf |title=Virtualization: architectural considerations and other evaluation criteria |publisher=VMware |access-date=8 September 2010 |url-status=live |archive-url=https://web.archive.org/web/20110206114316/http://www.vmware.com/pdf/virtualization_considerations.pdf |archive-date=6 February 2011}}</ref>{{rp|5}}<ref name=asplos/>{{rp|2}} This involves denying the guest OS any access to the actual page table entries by trapping access attempts and emulating them instead in software. The x86 architecture uses hidden state to store [[segment descriptor]]s in the processor, so once the segment descriptors have been loaded into the processor, the memory from which they have been loaded may be overwritten and there is no way to get the descriptors back from the processor. ''Shadow descriptor tables'' must therefore be used to track changes made to the descriptor tables by the guest OS.<ref name=pat242/>
* I/O device emulation: Unsupported devices on the guest OS must be emulated by a [[Emulator|device emulator]] that runs in the host OS.<ref name=pat847/>

These techniques incur some performance overhead due to lack of MMU virtualization support, as compared to a VM running on a natively virtualizable architecture such as the [[IBM System/370]].<ref name=asplos/>{{rp|10}}<ref name=tac9>{{cite web |url=http://download3.vmware.com/vmworld/2006/tac9463.pdf |title=VMware and Hardware Assist Technology |access-date=2010-09-08 |url-status=live |archive-url=https://web.archive.org/web/20110717231322/http://download3.vmware.com/vmworld/2006/tac9463.pdf |archive-date=2011-07-17}}</ref>{{rp|17 and 21}}

On traditional mainframes, the classic [[Hypervisor#Classification|type 1]] hypervisor was self-standing and did not depend on any operating system or run any user applications itself. In contrast, the first x86 virtualization products were aimed at workstation computers, and ran a guest OS inside a host OS by embedding the hypervisor in a kernel module that ran under the host OS (type 2 hypervisor).<ref name=pat847>{{US patent|6496847}}</ref>

There has been some controversy whether the x86 architecture with no hardware assistance is virtualizable as described by [[Popek and Goldberg virtualization requirements|Popek and Goldberg]]. [[VMware]] researchers pointed out in a 2006 [[International Conference on Architectural Support for Programming Languages and Operating Systems|ASPLOS]] paper that the above techniques made the x86 platform virtualizable in the sense of meeting the three criteria of Popek and Goldberg, albeit not by the classic trap-and-emulate technique.<ref name=asplos/>{{rp|2–3}}

A different route was taken by other systems like [[Denali (operating system)|Denali]], [[L4 microkernel family|L4]], and [[Xen]], known as [[paravirtualization]], which involves [[porting]] operating systems to run on the resulting virtual machine, which does not implement the parts of the actual x86 instruction set that are hard to virtualize. The paravirtualized I/O has significant performance benefits as demonstrated in the original [[Symposium on Operating Systems Principles|SOSP]]'03 Xen paper.<ref>{{cite web |url=http://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf |title=Xen and the Art of Virtualization |url-status=live |archive-url=https://web.archive.org/web/20140929081638/http://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf |archive-date=2014-09-29}}</ref>

The initial version of [[x86-64]] ([[X86-64#AMD64|AMD64]]) did not allow for a software-only full virtualization due to the lack of segmentation support in [[long mode]], which made the protection of the hypervisor's memory impossible, in particular, the protection of the trap handler that runs in the guest kernel address space.<ref>{{cite web |url=http://www.pagetable.com/?p=25 |title=How retiring segmentation in AMD64 long mode broke VMware |publisher=Pagetable.com |date=2006-11-09 |access-date=2010-05-02 |url-status=live |archive-url=https://web.archive.org/web/20110718104331/http://www.pagetable.com/?p=25 |archive-date=2011-07-18}}</ref><ref>{{cite web |url=http://download3.vmware.com/vmworld/2005/pac346.pdf |title=VMware and CPU Virtualization Technology |publisher=VMware |access-date=2010-09-08 |url-status=live |archive-url=https://web.archive.org/web/20110717231306/http://download3.vmware.com/vmworld/2005/pac346.pdf |archive-date=2011-07-17}}</ref>{{rp|11 and 20}} Revision D and later 64-bit AMD processors (as a rule of thumb, those manufactured in 90&nbsp;nm or less) added basic support for segmentation in long mode, making it possible to run 64-bit guests in 64-bit hosts via binary translation. Intel did not add segmentation support to its x86-64 implementation ([[Intel 64]]), making 64-bit software-only virtualization impossible on Intel CPUs, but Intel VT-x support makes 64-bit hardware assisted virtualization possible on the Intel platform.<ref>{{cite web |url=http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003945 |title=VMware KB: Hardware and firmware requirements for 64bit guest operating systems |publisher=Kb.vmware.com |access-date=2010-05-02 |url-status=live |archive-url=https://web.archive.org/web/20100419032716/http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003945 |archive-date=2010-04-19}}</ref><ref>{{cite web |url=http://www.vmware.com/files/pdf/software_hardware_tech_x86_virt.pdf |title=Software and Hardware Techniques for x86 Virtualization |access-date=2010-05-02 |url-status=dead |archive-url=https://web.archive.org/web/20100105124056/http://www.vmware.com/files/pdf/software_hardware_tech_x86_virt.pdf |archive-date=2010-01-05}}</ref>{{rp|4}}

On some platforms, it is possible to run a 64-bit guest on a 32-bit host OS if the underlying processor is 64-bit and supports the necessary virtualization extensions.