COMP 3000 Essay 2 2010 Question 9 - Revision history

Soma: Protected "COMP 3000 Essay 2 2010 Question 9" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-12-03T19:45:26Z

Protected "COMP 3000 Essay 2 2010 Question 9" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 19:45, 3 December 2010
(No difference)

Hesperus: /* Single-level architecture */

2010-12-03T11:41:21Z

Single-level architecture

← Older revision		Revision as of 11:41, 3 December 2010
Line 63:		Line 63:

	=====Single-level architecture=====		=====Single-level architecture=====
	The x86 based systems are based on the single-level of architecture virtualization support. In this hardware model, the host hypervisor L0 (running in Ring 0) handles all traps caused by any guest hypervisor running at any level of the virtualization stack. Assume that host hyperrvisor (L0) runs L1. When L1 attempts to run its own virtual machine called L2, this causes a trap that goes down to host hypervisor at level L0, L0 then handles the trap and initiates the required emulation for L1 to create L2. More generally, every trap occuring at level Ln, causes a drop to the L0 level where the host hypervisor resides. The host hypervisor then forwards this trap to the parent of Ln which is Ln-1, which in turn causes the trap to go down to L0 again, and so on. ~~This~~ trap handling switches ~~keeps~~ occurring until the desired emulated result reaches Ln to allow him the privilege to execute (Figure 2).		The x86 based systems are based on the single-level of architecture virtualization support. In this hardware model, the host hypervisor L0 (running in Ring 0) handles all traps caused by any guest hypervisor running at any level of the virtualization stack. Assume that host hyperrvisor (L0) runs L1. When L1 attempts to run its own virtual machine called L2, this causes a trap that goes down to host hypervisor at level L0, L0 then handles the trap and initiates the required emulation for L1 to create L2. More generally, every trap occuring at level Ln, causes a drop to the L0 level where the host hypervisor resides. The host hypervisor then forwards this trap to the parent of Ln which is Ln-1, which in turn causes the trap to go down to L0 again, and so on. Those trap handling switches keep occurring until the desired emulated result reaches Ln to allow him the privilege to execute (Figure 2).

	[[File:single-levelV.png\|thumb\|right\|Figure 2: The single-level architecture support for virtualization that relies on the host hypervisor (L0) to handle every trap caused by a guest.\|left\|400px]]		[[File:single-levelV.png\|thumb\|right\|Figure 2: The single-level architecture support for virtualization that relies on the host hypervisor (L0) to handle every trap caused by a guest.\|left\|400px]]

Hesperus: /* CPU Virtualization */

2010-12-03T11:21:25Z

CPU Virtualization

← Older revision		Revision as of 11:21, 3 December 2010
Line 108:		Line 108:

	==CPU Virtualization==		==CPU Virtualization==
	We illustrate the CPU virtualization implemented by the paper by using two level nested virtualization.		We illustrate the CPU virtualization implemented by the paper by using a two level nested virtualization (L0->L1->L2).

	Assume that L0 (the main host hypervisor) runs L1 as a virtual machine. L0 uses VMCS0->1 to run L1.		Assume that L0 (the main host hypervisor) runs L1 as a virtual machine. L0 uses VMCS0->1 to run L1.

Hesperus: /* Theory */

2010-12-03T11:19:53Z

Theory

← Older revision		Revision as of 11:19, 3 December 2010
Line 105:		Line 105:
	The fundamental idea of the Turtles Project relies on multiplexing the hardware among the involved nested virtual machines. When a virtual machine like L1 attempts to run L2, this triggers a trap that gets handled by L0, just as we illustrated earlier in the single-hardware architecture model. This trap includes the environment specifications that are needed to run L2 on the bare hardware. L0 converts L2's virtual memory to L1's virtual memory to make them run on the same level. This way, we flatten the virtualization levels and run L2 as an L1 virtual machine. We could generalize this scheme and keep running every new virtual machine on the L1 level. This way, we end up with a two dimensions architecture, bringing performance closer to the hardware level.		The fundamental idea of the Turtles Project relies on multiplexing the hardware among the involved nested virtual machines. When a virtual machine like L1 attempts to run L2, this triggers a trap that gets handled by L0, just as we illustrated earlier in the single-hardware architecture model. This trap includes the environment specifications that are needed to run L2 on the bare hardware. L0 converts L2's virtual memory to L1's virtual memory to make them run on the same level. This way, we flatten the virtualization levels and run L2 as an L1 virtual machine. We could generalize this scheme and keep running every new virtual machine on the L1 level. This way, we end up with a two dimensions architecture, bringing performance closer to the hardware level.

	However, one question that springs to mind, is that, if the host hypervisor ends up running and multiplexing the hardware among the guest virtual machines, then how can we keep track of the virtualization levels ? How can we know which virtual machine runs on top of the other ? The answer lies within the host hypervisor. By using special control structures like the VMCS and the VMCB, the hypervisor has the ability to diffrentiate between the ~~diffrent~~ levels and keep track of the different virtual environments and their associated guests.		However, one question that springs to mind, is that, if the host hypervisor ends up running and multiplexing the hardware among the guest virtual machines, then how can we keep track of the virtualization levels ? How can we know which virtual machine runs on top of the other ? The answer lies within the host hypervisor. By using special control structures like the VMCS and the VMCB, the hypervisor has the ability to diffrentiate between the different levels and keep track of the different virtual environments and their associated guests.

	==CPU Virtualization==		==CPU Virtualization==

Hesperus: /* Theory */

2010-12-03T11:19:20Z

Theory

← Older revision		Revision as of 11:19, 3 December 2010
Line 105:		Line 105:
	The fundamental idea of the Turtles Project relies on multiplexing the hardware among the involved nested virtual machines. When a virtual machine like L1 attempts to run L2, this triggers a trap that gets handled by L0, just as we illustrated earlier in the single-hardware architecture model. This trap includes the environment specifications that are needed to run L2 on the bare hardware. L0 converts L2's virtual memory to L1's virtual memory to make them run on the same level. This way, we flatten the virtualization levels and run L2 as an L1 virtual machine. We could generalize this scheme and keep running every new virtual machine on the L1 level. This way, we end up with a two dimensions architecture, bringing performance closer to the hardware level.		The fundamental idea of the Turtles Project relies on multiplexing the hardware among the involved nested virtual machines. When a virtual machine like L1 attempts to run L2, this triggers a trap that gets handled by L0, just as we illustrated earlier in the single-hardware architecture model. This trap includes the environment specifications that are needed to run L2 on the bare hardware. L0 converts L2's virtual memory to L1's virtual memory to make them run on the same level. This way, we flatten the virtualization levels and run L2 as an L1 virtual machine. We could generalize this scheme and keep running every new virtual machine on the L1 level. This way, we end up with a two dimensions architecture, bringing performance closer to the hardware level.

	However, one ~~should be prompted~~ to ~~ask the following:~~ if the host hypervisor ends up running and multiplexing the hardware among the guest virtual machines, then how can we keep track of the virtualization levels? The answer lies within the host hypervisor. By using special control structures like the VMCS and the VMCB, the hypervisor has the ability to diffrentiate between the diffrent levels and keep track of ~~which is on top of which~~.		However, one question that springs to mind, is that, if the host hypervisor ends up running and multiplexing the hardware among the guest virtual machines, then how can we keep track of the virtualization levels ? How can we know which virtual machine runs on top of the other ? The answer lies within the host hypervisor. By using special control structures like the VMCS and the VMCB, the hypervisor has the ability to diffrentiate between the diffrent levels and keep track of the different virtual environments and their associated guests.

	==CPU Virtualization==		==CPU Virtualization==

Hesperus: /* Compatibility */

2010-12-03T11:12:55Z

Compatibility

← Older revision		Revision as of 11:12, 3 December 2010
Line 70:		Line 70:

	====Compatibility====		====Compatibility====
	A user can run a particular application or OS that is not compatible with the existing or running OS as a virtual machine. Operating systems could also provide the user ~~with~~ a compatibility mode of other operating systems or applications. An example of this is the Windows XP mode that is available in Windows 7, where Windows 7 runs Windows XP as a virtual machine.		A user can run a particular application or OS that is not compatible with the existing or running OS as a virtual machine. Operating systems could also provide the user a compatibility mode of other operating systems or applications. An example of this is the Windows XP mode that is available in Windows 7, where Windows 7 runs Windows XP as a virtual machine.

	====Cloud computing====		====Cloud computing====

Hesperus: /* I/O virtualization */

2010-12-03T11:05:00Z

I/O virtualization

← Older revision		Revision as of 11:05, 3 December 2010
Line 139:		Line 139:


	The paper argues that, in a two level nested-virtualization (L0->L1->L2), we can theoretically mix and combine any two of those 3 approaches to implement I/O virtualization. For instance, we can implement device simulation at the L0->L1 level, but implement device assignment approach for the level L1->L2. However, the ~~autors choose~~ to focus their attention on ~~Direct~~ device assignment, since ideally it produces ~~the most efficient results and~~ best levels of performance.		The paper argues that, in a two level nested-virtualization (L0->L1->L2), we can theoretically mix and combine any two of those 3 approaches to implement I/O virtualization. For instance, we can implement device simulation at the L0->L1 level, but implement device assignment approach for the level L1->L2. However, the authors chose to focus their attention on direct device assignment, since ideally it produces best levels of performance.

	To get the best performance, they used a IOMMU (Input/Output memory management unit) for safe DMA (Device management assignemnt) bypass. With nested 3X3 options for I/O virtualization, they had the many options but they used multi-level device assignment giving L2 guest direct access to L0 devices bypassing both L0 and L1.		To get the best performance, they used a IOMMU (Input/Output memory management unit) for safe DMA (Device management assignemnt) bypass. With nested 3X3 options for I/O virtualization, they had the many options but they used multi-level device assignment giving L2 guest direct access to L0 devices bypassing both L0 and L1.

Hesperus: /* I/O virtualization */

2010-12-03T11:04:03Z

I/O virtualization

← Older revision		Revision as of 11:04, 3 December 2010
Line 134:		Line 134:
	here are 3 fundamental way to virtual machine access the I/O:		here are 3 fundamental way to virtual machine access the I/O:

	* Device emulation using a host hypervisor [10].		* Device emulation using a host hypervisor. [10]
	* Para-virtualized drivers that require modification of the guest kernel [11][12].		* Para-virtualized drivers that require modification of the guest kernel. [11][12]
	* Direct device assignment. Typically results in the best performance. [13][14]		* Direct device assignment. Typically results in the best performance. [13][14]

Hesperus: /* I/O virtualization */

2010-12-03T11:03:42Z

I/O virtualization

← Older revision		Revision as of 11:03, 3 December 2010
Line 132:		Line 132:
	==I/O virtualization==		==I/O virtualization==

	~~There~~ are 3 fundamental way to virtual machine access the I/O: Device emulation [10], Para-virtualized drivers ~~which knows it on a driver~~ [11][12] ~~and~~ Direct device assignment, [13][14] ~~which results~~ in the best performance. To get the best performance, they used a IOMMU for safe DMA bypass. With nested 3X3 options for I/O virtualization, they had the many options but they used multi-level device assignment giving L2 guest direct access to L0 devices bypassing both L0 and L1. To do this, they had to memory map I/O with program I/0 with DMA with interrupts. The idea with DMA is that of each hypervisor L0, L1 needs to use a IOMMU to allow its virtual machine to access the device in order to bypass safety. There is only one plate for IOMMU so L0 needs to emulate an IOMMU. L0 will then compress the Multiple IOMMU into a single hardware IOMMU page table so that L2 programs the device directly. The device DMA's are stored into the L2 memory space directly.		here are 3 fundamental way to virtual machine access the I/O:

			* Device emulation using a host hypervisor [10].
			* Para-virtualized drivers that require modification of the guest kernel [11][12].
			* Direct device assignment. Typically results in the best performance. [13][14]


			The paper argues that, in a two level nested-virtualization (L0->L1->L2), we can theoretically mix and combine any two of those 3 approaches to implement I/O virtualization. For instance, we can implement device simulation at the L0->L1 level, but implement device assignment approach for the level L1->L2. However, the autors choose to focus their attention on Direct device assignment, since ideally it produces the most efficient results and best levels of performance.

			To get the best performance, they used a IOMMU (Input/Output memory management unit) for safe DMA (Device management assignemnt) bypass. With nested 3X3 options for I/O virtualization, they had the many options but they used multi-level device assignment giving L2 guest direct access to L0 devices bypassing both L0 and L1.
			To do this, they had to memory map I/O with program I/0 with DMA with interrupts. The idea with DMA is that of each hypervisor L0, L1 needs to use a IOMMU to allow its virtual machine to access the device in order to bypass safety. There is only one plate for IOMMU so L0 needs to emulate an IOMMU.
			L0 will then compress the Multiple IOMMU into a single hardware IOMMU page table so that L2 programs the device directly. The device DMA's are stored into the L2 memory space directly.

	==Macro optimizations==		==Macro optimizations==

Hesperus: /* Conclusion */

2010-12-03T10:51:49Z

Conclusion

← Older revision		Revision as of 10:51, 3 December 2010
Line 158:		Line 158:

	=== Conclusion ===		=== Conclusion ===
	Some could argue that the research showed in the Turtles Project is the first to achieve a level of efficieny in x86 nested-virtualization without altering the hardware, relying on improved techniques and mechanisms. This is a major improvement over the current available solutions. The paper has garnered a lot of attention and appraisal from the computing world including the Jay Lepreau best paper award. More recently, a paper on nested virtualization that examines trap forwarding has been published by the VMWare research lab [18], the paper makes references and uses some of the data that was published and documented in the Turtles Project.		Some could argue that the research showed in the Turtles Project is the first to achieve a significant level of efficieny in x86 nested-virtualization without altering the hardware, relying on improved techniques and mechanisms. This is a major improvement over the current available solutions. The paper has garnered a lot of attention and appraisal from the computing world including the Jay Lepreau best paper award. More recently, a paper on nested virtualization that examines trap forwarding has been published by the VMWare research lab [18], the paper makes references and uses some of the data that was published and documented in the Turtles Project.

	=References=		=References=