Month: August 2017

CPU virtualization
* illusion of owning the cpu
* handle program discontinues
Devise virtualization

First part
– illusion of ownership of cpu for each vm
Second part(common to full + pava)
– delivering events to parent guest OS
– address translation on every memory access

Full virtualization
-trap and emulate
– implicit guest -> hypervisor
-software interrupts(event) hypervisor -> guest
Para virtualization
-more opportunity for innovation
– explicit guest -> hypervisor
– software interrupts hypervisor -> guest

Data transfer
– implicit, explicit => opportunity to innovate

Xen’s async i/o rings

Measuring Time
cpu, memory storage, network

Thorny issue
– handling virtual memory
key functionality

Applications
OS memory management subsystem
hardware physical memory

p1, p2
Windows, linux: physical memory
Hypervisor: machine memory
Hardware
each process in its own protection domain -> distinct PT in respective os

virtualized
VPN -> PT -> PPN -> S-PT -> MPN
s-pt updated by hypervisor
translation installed into TLB/hardware PT

Efficient Mapping
shift burden to guest os
-maintain contiguous “physical memory”
-map to discountiguous hardware pages

memory systems, data centers, jvm, virtual box, ibm vm, google glass, cloud computing, dalvik(android), vmware work station, inception, and so on.

Platform virtualization
Alize Inc.
app, app, app
->
windows, linux, windows
Shared Hardware

Hypervisors
Native(bare metal)
guest os, guest os, guest os
Hypervisor
Shared Hardware

Microkernel-based OS structure
app1 app2 …
file system, memory manager, cpu scheduler: each service in its own address space
m kernel: simple abstraction, address space, IPC
Hardware

Border crossing
– implicit + explicit costs
Protected procedure calls
– 100x normal procedure calls

L3 Mkernel
Thesis: It’s all about efficient implementation
proof by construction to debunk myths about MicroKenerl-based os structure

Strikes Against Microkernel
Kernel-user switches
– border crossing cost
Address space swtiches
– basis for ppc for cross protection domain calls

Thread switches + IPC
– kernel mediation for ppc

Memory effects
– Locality loss
ff <-> storage

Debunking User Kernel Border Crossing Myth
-empirical proof
L3: processor cycles
* includes TLB and cache misses

Mach
– 900 cycles

SPIN and exokernel used mach as locsis for decrying MKernel-based design

Address space swtiches
VPN tag:index – match – TLB:tag PFN – PFN

Large Protection Domain
fs => hardware address space

Large protection domain
– need TLB-flush if not as – tagged
Hardware address space = storage
– explicit cost << implicit cost e.g., 864 cycles for TLB flush in pentium upshot for address space switching small protection domains large protection domains Memory effect VM, memory, L3, L2, L1, CPU TLB Reasons for Mach's expensive border crossing - focus on portability large memory, lesser locality, more cache missing

Decouple Authorization from use
use bindings
library os: semantic of use in library
exokernel: ask for resource
hardware: bind library os to hardware resources

Examples of candidate resources
-TLB entry
* virtual to physical mapping done by library
* binding prerseated to exokernel
* exokernel puts it into hardware TLB
* process in library os uses multiple times without exokernel intervention
-Packet filter
* predicates loaded into kernel by library os
* checked on PKT arrival by exokernel

Implementing secure bindings
– hardware mechanisms
* e.g., TLB entry
– software caching
* shadow TLB in software for each library os

Library OS
Exokernel
TLB, CPU

CPU scheduling
– linear vector of “time slots”
time quantum

Revocation of resources
space(memory) and time(cpu)
library os: revoke(repossession vector)
exokernel

App1, App2, … Appn　-> each app in its own hardware address space
OS Service and Devices Drivers -> os in its own hardware address space
Hardware -> managed by the OS

Dos-like
Microkernel-based
Monolithic

SPIN mechanisms for event
event-based communication model
event – spin dispatcher, event handlers

Ping, rpc, fwd, http
icmp, udp, tcp
ip pkt arrive
ip
ethernet pkt, atm pkt

default core services in spin
Memory management
-physical address
* allocate, deallocate, reclaim
-virtual address
* allocate, deallocate
-translation
* create/ destory AS, add/remove mapping
-Event handler
* page fault, access fault, badd address
CPU scheduling
-spin abstraction:strand
* semantics defined by extension
-event handlers
* block, unblock, checkpoint, resume
-spin global scheduler
* interact with appliction

SPIN and External approaches to OS extensibility
L3: Micro kernel-based approach to OS extensibility

OS service example
process, memory management, interprocess communication(ipc), file system, access to I/O devices, access to the network

Why the structure of the OS is important?
-protection, performance, flexibility, scalability, agility, responsiveness

Protection: within and across users + the OS itself
Performance: Time taken to perform the services
Flexibility: Extensibility => not one size at all
Scalability: performance if hardware resources
Agility: adapting to changes in application needs and/or resource availability
Responsiveness: reaching to external events

Commercial OS
– Linux, MacOS, Windows

OS abstraction

Resource needs of applications
-cpu, memory, peripheral devices
app launch time
– know how to create memory
App – os loader – stack, heap, global data memory
App asks for additional resources at runtime

Processor related OS abstractions
– program => static image loaded into memory
– process => a program in execution
Process = program + state => evolves as the program executes

variety of platforms — cell phones, multi-core, parallel systems, distributed systems, and cloud computing.

Digging deeper into the power of abstruction
Google earth
<-> series of abstruction <->
Electrons, Transistors, Logic gates, Seq. + comb.Logic element, machine organization(Data path + control), Instruction set architecture, System software(os, compilers, etc), Applications

Hardware continuum
smartphone, tablet laptop, desktop, server, cloud

Internal organization
– same for all manifestations
Contr, CPU, memory, Bus, contr, Network

System Bus(Higher speed), frame buffer and I/O Bus(Lower speed) connected with Bridge

OS is a resource manager
OS provides a consistent interface to the hardware resources
OS schedules applications on the cpu

OS protected access to hardware resources
-arbitrate among competing requests