System Virtualization
This content explores system virtualization concepts such as paravirtualization and full virtualization, comparing their differences and benefits. It also delves into control transfer mechanisms and the impacts on CPU and memory handling in virtualized environments. Additionally, it discusses the cost considerations associated with paravirtualization in systems like Xen.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
System Virtualization Michael Bechtel
Outline Paravirtualization (Xen) Handling Physical Memory
Full Virtualization Assume a classic virtual machine. App 1 App 2 App 1 App 2 Run unmodified guest OSes. Guests think they're baremetal in privileged mode. All communications with the VMM are implicit. OS 1 OS 2 VMM Hardware
Drawbacks CPU Need to scan and patch problem instructions. Memory Need to maintain shadow page tables. I/O Devices Need to virtualize numerous devices. Each device is controlled in a different way. Xen's approach = Paravirtualization. Formally introduced by the Denali VMM1in 2002. 1Whitaker, Andrew, Marianne Shaw, and Steven D. Gribble. Denali: Lightweight virtual machines for distributed and networked applications. Technical Report 02-02-01, University of Washington, 2002.
Paravirtualization Modify the guest OS to interact with the VMM. VMM provides an API that the modified guest OS uses. Applications don't see anything different. App 1 App 2 App 1 App 2 Guest OS communicates with VMM. Can see and utilize underlying hardware. Changes how system virtualization is done. OS 1 OS 2 VMM Hardware
Cost of Paravirtualization In Xen1, the number of guest OS changes were (relatively) minimal: Modern OSes come with VMM interfaces. Windows Hyper-V, Linux KVM. 1Barham, Paul, et al. Xen and the art of virtualization. ACM SIGOPS operating systems review. Vol. 37. No. 5. ACM, 2003.
Control Transfer Guest OS uses hypercalls to transfer control to the VMM. Transfers between VMM and guests are explicit. VMM returns control to the guest OS through software events. Same as full virtualization. Guest OS can communicate to VMM when to send interrupts. In full virtualization, interrupts are sent as they occur.
Paravirtualization - CPU The guest OS knows it's running in user mode. When executing a sensitive instruction, the guest OS communicates to and has the VMM execute the instruction. This includes any problem instructions that may be called. Removes need for scanning and patching the guests. The guest OS can register exception handlers for system calls. The VMM validates the handler before it's placed in the hardware exception table. Any future invocations of that system call execute directly on the processor.
Paravirtualization - Memory Guest OS knows its "real" memory isn't real. Have guest OS maintain virtual-to-physical page mappings. Removes need for VMM to maintain shadow page tables. Give guest OS read access to hardware page tables (through hypercalls): Create page table. Switch page table. Update page table. VMM validates any page table changes made by guest OS. Ensures the guest is assigned to the relevant page table.
Paravirtualization - I/O Devices Guest OS sees the same devices as the VMM. VMM is an additional layer between guest OSes and I/O devices. Need to transfer data with minimal overhead. Create device abstractions. Guest OS interacts with devices through provided interfaces. Increases possibilities for I/O virtualization. Xen I/O Rings Circular data structure comprised of descriptors. The guest OS and VMM act as both producers and consumers. Guest OS produces requests, consumes responses. VMM produces responses, consumes requests. Guests pass pointers to Xen, no actual data is placed in the I/O Rings.
Request producer Response consumer Shared Updated by guest Private to guest Physical memory Physical memory 4 1 3 2 Physical memory Physical memory Request consumer Response producer Shared Updated by VMM Private to VMM
Example: Networking Receive Transmit To receive a packet, guests must trade an unused page. Packet is dropped if no pages are available. Guest transmits packets through requests. Pages must be pinned. Xen uses a round-robin packet scheduler.
Outline Paravirtualization (Xen) Handling Physical Memory
Consolidating Multiple VMs Goal: run multiple VMs on one machine. Reality: physical resources (memory) are finite. OS 1 OS 2 I need more memory. Real memory Real memory VMM Physical memory What if there's no physical memory left?
Dynamic Memory Allocation Ideally, reclaim unused memory from some VM(s) and give it to others that need it. Reclaimed memory would be written to the VMM's swap memory. The VMM would need its own page replacement policy. Which VM(s) to reclaim from? Which pages to reclaim? The VMM is unaware of which pages are important. Only the guest OSes have knowledge of this. Forcefully reclaiming memory can cause performance loss and/or unintended behaviors.
OS 1 OS 2 I need more memory. That was important! Real memory Real memory VMM Physical memory
Ballooning Trick guest OS into willingly giving up or getting more memory. Install a "balloon" device driver that is maintained by the VMM. Works in both fully virtualized and paravirtualized systems. Guest OS More memory for guest Deflate Balloon Guest OS Balloon Guest OS Less memory for guest Balloon Inflate
Memory Sharing Between VMs App App OS 1 OS 2 VMM Real memory How to prevent duplicate physical pages?
Content-Based Page Sharing Use a content hash value to find possibly identical pages. VMM maintains a lookup table that uses hash values as keys. All entries (frames) contain the content hash and physical page number. Unshared pages are hint frames. Contain parent VM and real page number. Shared pages are shared frames. Contain number of references. If two hashes match, perform full comparison. If identical, update the guest page's mapping and reclaim the copied physical page.
Hash contents Binary contents ...0123 VM 1 VM 2 Hint frame Physical memory Hash: ...0123 PPN: abcd VM: 2 RPN: 4567 Lookup table Assume the pages are identical.
Hash contents Binary contents ...0123 VM 1 VM 2 Shared frame Physical memory Hash: ...0123 PPN: abcd Refs: 2 1. Update page mapping. 2. Reclaim duplicate page. 3. Hint frame -> Shared frame. Lookup table