Operating Systems: Components and Duties

1. Operating Systems:Components and Duties NOTE: this lecture and the next two lectures are intended to provide an overview of OS concepts important to the study of embedded systems. For more comprehensive information, please visit the website listed at the bottom of the slides and the material accessible there. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

2. What is an Operating System? • A program that acts as an intermediary between a user of a computer and the computer hardware. • Operating system goals: • Execute user programs and make solving user problems easier. • Make the computer system convenient to use. • Use the computer hardware in an efficient manner. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

3. System Components Hides the complexity of machine language from programmer Instruction Set Architecture Physical devices grouped together to form functional units Integrated circuit chips, power supply, CRT • The operating system runs in kernel or supervisor mode - protected from user tampering • Compilers, editors and application programs run in user mode Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

4. Functions of an OS • User Environment - OS layer transforms bare hardware machine into higher level abstractions • Execution environment - process management, file manipulation, interrupt handling, I/O operations, language. • Error detection and handling • Protection and security • Fault tolerance and failure recovery Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

5. Functions of an OS (continued) • Resource Management • Time management • CPU and disk transfer scheduling • Space management • main and secondary storage allocation • Synchronization and deadlock handling • IPC, critical section, coordination • Accounting and status information • resource usage tracking Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

6. Typical memory layout Several jobs are kept in main memory at the same time, and the CPU is multiplexed among them. • OS tasks: • Memory management – the system must allocate the memory to several jobs. • CPU scheduling – the system must choose among several jobs ready to run. • Allocation of devices. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

7. Real-Time Systems • Designed for a dedicated application such as scientific experiments or industrial processes, medical imaging and devices, consumer products, avionics, and automobiles • Responsibilities have well-defined, fixed time constraints • Hard real-time: • MISSED DEADLINE IS A SYSTEM FAILURE • Secondary storage limited or absent, data stored in short term memory, or read-only memory (ROM) • Not supported by general-purpose operating systems. • Firm real-time • OCCASIONAL MISSED DEADLINES ARE TOLERABLE but quality of service may degrade • a result is useless if it is provided after the deadline • Soft real-time • The usefulness of a result and the quality of service degrade if the result is provided after the deadline • System may attempt to maximize the number of deadlines met or the number of high-priority tasks meeting their schedules or to minimize the lateness of tasks, for example Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

8. Computer-System Operation • Starting up a computer • Initial program, or bootstrap program, is run • Stored in ROM or EPROM within the computer hardware • Initializes all aspects of the computer (registers, controllers, memory etc.) • Loads the operating system and executes it • Locates and loads the OS kernel • Once loaded, the OS waits for an event to occur • Events usually signaled by an interrupt from either the hardware or software • Hardware sends a signal to the CPU via the system bus • Software triggers an interrupt by executing a system call Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

9. Device Controller • A computer system typically consists of a CPU and multiple device controllers connected through a common bus • Each device controller is in charge of a specific device or multiple devices (e.g. SCSI controller) • Device controller maintains local buffer storage and a set of special purpose registers • The device controller moves data between the device it controls and its local buffer storage Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

10. Interrupts • Interrupts enable software to respond to signals from hardware • May be initiated by a running process • Interrupt is called a trap – software generated caused by error or user request for an OS service • Dividing by zero or referencing protected memory • May be initiated by some event that may or may not be related to the running process • Key is pressed on a keyboard or a mouse is moved • Low overhead • Polling is an alternative approach • Processor repeatedly requests the status of each device • Increases in overhead as the complexity of the system increases Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

11. Handling Interrupts • After receiving an interrupt, the processor completes execution of the current instruction, then pauses the current process • The processor will then transfer to a fixed location and executes the service routine for the interrupt • The interrupt handler determines how the system should respond • Interrupt handlers are stored in an array of pointers called the interrupt vector • To handle the interrupt quickly, a table of pointers is generally stored in low memory which hold the addresses of the ISR for the various devices • This array, or interrupt vector, of addresses is then indexed by a unique device number to provide the address of the ISR for the interrupting device • After the interrupt handler completes, the interrupted process is restored and execution continues from the address of the interrupted instruction (stored on stack) or the next process is executed Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

12. Interrupt Classes EXAMPLE: Intel IA-32 exception classes Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

13. Interrupt Classes EXAMPLE: Intel IA-32 exception classes (continued) Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

14. I/O Interrupts • To start an I/O operation, the CPU loads the appropriate registers within the device controller • The device controller examines the values and determines what action to take (e.g. read, write) • When the transfer is complete, the device controller informs the CPU via an interrupt • The device driver returns control to the OS • Returns the data or pointer to the data if a read was done • For other operations it returns status information Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

15. I/O Interrupts • Synchronous: • After I/O starts, control returns to user program only upon I/O completion. • Wait instruction or tight loop (Loop: jmp Loop) idles the CPU until the next interrupt • At most one I/O request is outstanding at a time, no simultaneous I/O processing. • Asynchronous: • After I/O starts, control returns to user program without waiting for I/O completion. • Increased system efficiency by increasing CPU utilization Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

16. Device-Status Table • Device-status table contains entry for each I/O device indicating its type, address, and state. • Operating system indexes into I/O device table to determine device status and to modify table entry to include interrupt. • If the device is busy with a request, the type of request and other parameters are stored in the table entry for that device • A queue will contain a list of all those requests waiting for a device Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

17. Hardware Protection • Dual-Mode Operation • I/O Protection • Memory Protection • CPU Protection Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

18. Dual-Mode Operation • Sharing system resources requires operating system to ensure that an incorrect program cannot cause other programs to execute incorrectly as well as to protect the OS from errant user programs • Provide hardware support to differentiate between at least two modes of operations. • User mode – execution done on behalf of a user. • Monitor mode (also kernel mode or system mode) – execution done on behalf of operating system. • MS-DOS for the Intel 8088 had no mode bit • User program can wipe out the OS • Multiple programs can write to a device simultaneously Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

19. Dual-Mode Operation (Cont.) • Mode bit added to computer hardware to indicate the current mode: monitor (0) or user (1). • When an interrupt or trap (program error) occurs hardware switches to monitor mode. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

20. I/O Protection • All I/O instructions are privileged instructions. • Must ensure that a user program could never gain control of the computer in monitor mode (i.e., a user program that, as part of its execution, stores a new address in the interrupt vector). • System call - A privileged instruction provides a means for the user to interact with the OS to perform tasks that only the OS can do • Treated by the hardware as a software interrupt • Switch to monitor mode jumping to the address determined by the interrupt vector Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

21. Memory Protection • Must provide memory protection at least for the interrupt vector and the interrupt service routines. • In order to have memory protection, add two registers that determine the range of legal addresses a program may access: • Base register – holds the smallest legal physical memory address. • Limit register – contains the size of the range • Memory outside the defined range is protected. • Base and limit registers can be loaded only by the OS which uses a special privileged instruction (which can be executed only in monitor mode) Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

22. Use of A Base and Limit Register Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

23. Hardware Protection • CPU hardware compares every address generated in user mode with the registers • Any violation results in a trap to the monitor which treats it as a fatal error • When executing in monitor mode, the operating system has unrestricted access to both monitor and user’s memory. • The load instructions for the base and limitregisters are privileged instructions. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

24. CPU Protection • Timer – interrupts computer after specified period to ensure operating system maintains control. • Timer is decremented every clock tick. • When timer reaches the value 0, an interrupt occurs. • Timer commonly used to implement time sharing • interrupt every N milliseconds (a time slice) at which time a context switch occurs • Performs housekeeping on the program just stopped, saves registers, internal variables, buffers etc. and prepares for the next program to run • Load-timer is a privileged instruction. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

25. Protection and Security • Protection controls the access of processes or users to the resources of the computer system • Distinguish between authorized and unauthorized use • Security defends a system from external and internal attacks • Viruses, worms, denial of service attacks, identify theft Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

26. Operating-System Structures • System Components • Operating System Services • System Calls • System Programs • System Structure • Virtual Machines • System Design and Implementation Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

27. Common System Components A system as large and complex as an OS can be created only by partitioning it into smaller pieces* • Process Management • Main Memory Management • File Management • I/O System Management • Secondary Management • Networking • Protection System • Command-Interpreter System *italicized topics will not be discussed here Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

28. Process Management • A process is a program in execution. A process needs certain resources, including CPU time, memory, files, and I/O devices, to accomplish its task. • A process is the unit of work in a system • The operating system is responsible for the following activities in connection with process management. • Process creation and deletion. • Process suspension and resumption. • Provision of mechanisms for: • process synchronization • process communication Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

29. I/O System Management • Hide the peculiarities of specific hardware devices from the user • The I/O system consists of: • A memory management component that includes buffering, caching and spooling • A general device-driver interface • Drivers for specific hardware devices Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

30. Protection System • Protection refers to a mechanism for controlling access by programs, processes, or users to both system and user resources. • The protection mechanism must: • distinguish between authorized and unauthorized usage. • specify the controls to be imposed. • provide a means of enforcement. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

31. Command-Interpreter System • Serves as the interface between the user and the OS • User friendly, mouse based windows environment in the Macintosh and in Microsoft Windows • In MS-DOS and UNIX, commands are typed on a keyboard and displayed on a screen or printing terminal with the Enter or Return key indicating that a command is complete and ready to be executed • Many commands are given to the operating system by control statements which deal with: • process creation and management • I/O handling • secondary-storage management • main-memory management • file-system access • protection • networking Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

32. Command-Interpreter System (Cont.) • The program that reads and interprets control statements is called variously: • command-line interpreter • shell (in UNIX) Its function is to get and execute the next command statement. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

33. System Calls • System calls provide the interface between a running program and the operating system. • For example – open input file, create output file, print message to console, terminate with error or normally • Generally available as routines written in C and C++ • Certain low-level tasks (direct hardware access) may be written in assembly-language • Mostly accessed by programs via a high-level Application Program Interface (API) rather than direct system call use • Provides portability (underlying hardware handled by OS) • Hides the detail from the programmer • Three most common APIs are Win32 API for Windows, POSIX API for POSIX-based systems (including virtually all versions of UNIX, Linux, and Mac OS X), and Java API for the Java virtual machine (JVM) Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

34. Example of Standard API • Consider the ReadFile() function in the • Win32 API—a function for reading from a file • A description of the parameters passed to ReadFile() • HANDLE file—the file to be read • LPVOID buffer—a buffer where the data will be read into and written from • DWORD bytesToRead—the number of bytes to be read into the buffer • LPDWORD bytesRead—the number of bytes read during the last read • LPOVERLAPPED ovl—indicates if overlapped I/O is being used Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

35. System Call Implementation • Typically, a number associated with each system call • System-call interface maintains a table indexed according to these numbers • The system call interface invokes intended system call in OS kernel and returns status of the system call and any return values • The caller need know nothing about how the system call is implemented • Just needs to obey API and understand what OS will do as a result call • Most details of OS interface hidden from programmer by API • Managed by run-time support library (set of functions built into libraries included with compiler) Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

36. API – System Call – OS Relationship Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

37. Standard C Library Example • C program invoking printf() library call, which calls write() system call Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

38. System Call Parameter Passing • Often, more information is required than simply identity of desired system call • Exact type and amount of information vary according to OS and call • Three general methods used to pass parameters to the OS • Simplest: pass the parameters in registers • In some cases, may be more parameters than registers • Parameters stored in a block, or table, in memory, and address of block passed as a parameter in a register • This approach taken by Linux and Solaris • Parameters placed, or pushed, onto the stack by the program and popped off the stack by the operating system • Block and stack methods do not limit the number or length of parameters being passed Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

39. Passing Parameters as a Table Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

40. Types of System Calls • Process control • end, abort, load, execute, allocate/free memory • File management • Create/delete file, open, close, read, write • Device management • Request/release device, read, write • Information maintenance • Get/set date or time, get process, get/set system data • Communications • Send/receive message, create/delete comm link Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

41. Example: UNIX System Calls Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

42. UNIX Running Multiple Programs • FreeBSD is a multitasking system • Shell accepts a command to run a program but, unlike MS-DOS, continues to run while the other program is executing • To start a new process, the shell executes a fork system call which enables another program to be loaded into memory and executed • A process can run in the “background” but then it can not accept input from the keyboard (as it is dedicated to the shell) but can read and writes files • The shell again waits for further commands – run another program, monitor the progress of the running processes, change priorities, etc. • When a process terminates it issues an exit system call returning a status code Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

43. UNIX Running Multiple Programs Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

44. System Programs • System programs provide a convenient environment for program development and execution. The can be divided into: • File manipulation • Status information (date,time, # of users, free memory etc.) • File modification (text editors) • Programming language support (compilers, assemblers, etc) • Program loading and execution (loaders, linkage editors) • Communications (create virtual connections among processes, users and different computer systems) • System utilities or application programs (web browsers, word processing, spreadsheets etc) • Most users’ view of the operating system is defined by system programs, not the actual system calls. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

45. OS Design Implementation • Mechanisms determine how to do something, policies decide what will be done. • The separation of policy from mechanism is a very important principle in designing an OS • It allows maximum flexibility if policy decisions are to be changed later. • The mechanism that implements the policy to give priority to I/O intensive processes over CPU intensive processes should be written in a general way so that if the policy is changed no or minimal change to the mechanism would be required • The timer provides is a mechanism providing CPU protection. How long it runs for a particular user is a policy decision. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

46. System Implementation • Traditionally written in assembly language, operating systems can now be written in higher-level languages. • Code written in a high-level language: • can be written faster. • is more compact. • is easier to understand and debug. • Opponents to OS written high-level language claim slower performance and increased storage • Proponents argue: • Modern compilers can produce highly optimized code • Todays OSs run on highly complex hardware which can overwhelm the programmer with details • Better data structures and algorithms will truly improve the performance of OSs • Only a small amount of code is critical to high performance – bottlenecks can be replaced with assembler code later on • An operating system is far easier to port (move to some other hardware) if it is written in a high-level language. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

47. Operating System Structure: MS-DOS • MS-DOS – written to provide the most functionality in the least space • Not well divided into modules • Designed without realizing it was going to become so popular • Although MS-DOS has some structure, its interfaces and levels of functionality are not well separated • Vulnerable to system crashes when a user program fails • Written for Intel 8088 which had no dual mode or hardware protection MS-DOS layer structure Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

48. Operating System Structure: UNIX • UNIX – the original UNIX operating system had limited structuring due to limited hardware functionality. • The UNIX OS consists of two separable parts. • Systems programs • The kernel – series of interfaces and device drivers • Consists of everything below the system-call interface and above the physical hardware • Provides the file system, CPU scheduling, memory management, and other operating-system functions; a large number of functions for one level. • All this functionality in one level makes UNIX difficult to enhance – difficult to determine impact of change in one part of the kernel on other parts Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

49. UNIX System Structure kernel Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)

50. Virtual Machines • A virtual machine treats hardware and the operating system kernel as though they were all hardware. • A virtual machine not provide any additional functionality but provides an interface identical to the underlying bare hardware. Each process is provided with a (virtual) copy of the underlying computer • The operating system creates the illusion that a process has its own processor with its own (virtual) memory. • The resources of the physical computer are shared to create the virtual machines. • CPU scheduling can create the appearance that users have their own processor. • Spooling and a file system can provide virtual card readers and virtual line printers. • A normal user time-sharing terminal serves as the virtual machine operator’s console. Ref: http://userhome.brooklyn.cuny.edu/irudowdky/OperatingSystems.htm & Silberschatz, Gagne, & Galvin, Operating Systems Concepts, 7thed, Wiley (ch 1-3)