1 / 27

OS Structures - Xen

OS Structures - Xen. Xen. Key points. Goal: extensibility akin to SPIN and Exokernel goals Main difference: support running several commodity operating systems on the same hardware simultaneously without sacrificing performance or functionality Why? Application mobility

dannon
Télécharger la présentation

OS Structures - Xen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OS Structures - Xen

  2. Xen

  3. Key points • Goal: extensibility akin to SPIN and Exokernel goals • Main difference: support running several commodity operating systems on the same hardware simultaneously without sacrificing performance or functionality • Why? • Application mobility • Server consolidation • Co-located hosting facilities • Distributed web services • ….

  4. Old idea • VM 370 • Virtualization for binary support for legacy apps • Why resurgence today? • Companies want a share of everybody’s pie • IBM zSeries “mainframes” support virtualization for server consolidation • Enables billing and performance isolation while hosting several customers • Microsoft has announced virtualization plans to allow easy upgrades and hosting Linux! • You can see the dots connecting up • From extensibility (a la SPIN) to virtualization

  5. Possible virtualization approaches • Standard OS (such as Linux, Windows) • Meta services (such as grid) for users to install files and run processes • Administration, accountability, and performance isolation become hard • Retrofit performance isolation into OSs • Linux/RK, QLinux, SILK • Accounting resource usage correctly can be an issue unless done at the lowest level (e.g. Exokernel) • Xen approach • Multiplex physical resource at OS granularity

  6. Full virtualization • Virtual hardware identical to real one • Relies on hosted OS trapping to the VMM for privileged instructions • Pros: run unmodified OS binary on top • Cons: • supervisor instructions can fail silently in some hardware platforms (e.g. x86) • Solution in VMware: Dynamically rewrite portions of the hosted OS to insert traps • need for hosted OS to see real resources: real time, page coloring tricks for optimizing performance, etc…

  7. Xen principles • Support for unmodified application binaries • Support for multi-application OS • Complex server configuration within a single OS instance • Paravirtualization for strong resource isolation on uncooperative hardware (x86) • Paravirtualization to enable optimizing guest OS performance and correctness

  8. Xen: VM management • What would make VM virtualization easy • Software TLB • Tagged TLB =>no TLB flush on context switch X86 does not have either • Xen approach • Guest OS responsible for allocating and managing hardware PT • Xen top 64MB of every address space. Why?

  9. x86 Memory Management • Segments • CS (code); SS (stack); DS, ES, FS, GS (all data) • Base address and limit checking • Segment base concatenated with CPU address is the linear 32-bit virtual address • 4KB pages • Top 10 bits of address: page table • Next 10 bits of address: page table entry

  10. Creating a new PT by Guest OS • allocate and initialize a page and registers it with Xen to serve as the new PT • all subsequent updates to this page (i.e. PT) via Xen • can batch updates to reduce the cost of entering and exiting Xen • Segmentation by guest OS virtualized similarly

  11. Xen: CPU virtualization • Four privilege levels in x86 • Ring 0 (Xen) • Ring 1 (guest OS) • Ring 3 (apps of the guest OS) • Privileged instructions • Validated and executed in Xen (e.g. installing a new PT) • Exceptions • Registered with Xen once • Called directly without Xen intervention • All syscalls from apps to guest OS handled this way • Page fault handlers are special • Faulting address can be read only in ring 0 • Xen reads the faulting address and passes it via stack to the OS handler in ring 1

  12. Xen: Device I/O virtualization • Set of clean and simple device abstractions • Allows buffers to be passed directly to/from guest OS to I/O devices • Event delivery mechanism for sending asynchronous notifications to the guest OS

  13. Details of subsystem virtualization • Control transfer • Data transfer These are used in the virtualization of all the subsystems

  14. Control transfer • Hypercalls from guest OS to Xen • E.g. set of page table updates • Events for notification from Xen to guest OS • E.g. data arrival on network; virtual disk transfer complete • Events may be deferred by a guest OS (similar to disabling interrupts)

  15. Data transfer – I/O rings • Resource management and accountability • CPU time • Demultiplex data to the domains quickly upon interrupt • Account computation time for managing buffers to the appropriate domain • Memory buffers • relevant domains provide memory for I/O to Xen • Xen pins page frames during I/O transfer

  16. I/O descriptors indirectly reference the actual memory buffers

  17. Each request: unique ID from guest OS • Response: use this unique ID • Network packets • Represented by a set of requests • Responses to these signal packet reception • Disk requests • May be reordered for flexibility • Zero copy semantics via the descriptors • Domain my enqueue multiple entries before invoking a hypercall requests • Ditto for responses from Xen

  18. CPU scheduling • Base Xen scheduler uses BVT algorithm [Duda & Cheriton, SOSP 99] • Work conserving for different domains (ensuring accountability) with a low-latency wake up on event arrival using virtual time warping

  19. Time and timers • Guest OSs have access to Xen’s • Real time (cycle counter accuracy for real time tasks in guest OSs) • Virtual time (enables time slicing within the guest OS) • Wall clock time (real time + domain changeable offset) • Guest OS maintain their own internal timer queues and use a pair of Xen timers (real and virtual)

  20. Virtual address translation • VMware solution • Each domain with shadow page table • Hypervisor go between the VMM and MMU • Xen solution (similar to Exokernel) • Register guest OS PT directly with MMU • Guest OS has read only access • All mods to the PT via Xen • Type associated with a page frame • PD, PT, LDT, GDT, RW • All except RW: read-only access to the page for guest OS • Guest OS can retask a page only when ref count is 0

  21. Physical memory • At domain creation, hardware pages “reserved” • Domain can increase/decrease its quota • Xen does not guarantee that the hardware pages are contiguous • Guest OS can maintain “physical memory” that is contiguous mapped to the “hardware pages”

  22. Network • Each guest OS has two I/O rings • Receive and transmit • Transmit • Enqueue descriptor on the transmit ring • Points to the buffer in guest OS space • No copying into Xen • Page pinned till transmission complete • Round robin packet scheduler across domains • Receive • Exchange received page for a page of the guest OS in the receive ring • No copying

  23. Disk • Batches of requests from competing domain taken and scheduled • Since Xen has knowledge of disk layout, requests may be reordered • No copying into Xen • “Reoder barrier” to prevent reordering (may be necessary for higher level semantics such as write ahead log)

  24. Performance

More Related