The IBM VM Operating System



The IBM VM Operating System

CS-550-2: Operating Systems

Fall 2003

Stephen Kam

Table of Contents:

1. Introduction …………………………………………………………………. p.1

2. Overview ……………………………………………………………………. p.1

3. Processor Modes ……………………………………………………………. p.3

4. Multiprogramming/Multiprocessing ………………………………………... p.4

5. Process States ……………………………………………………………….. p.6

6. Memory Management ………………………………………………………. p.6

7. Conclusion ………………………………………………………………….. p. 7

Introduction:

In 1972, IBM debuted its VM (virtual machine) operating system, which was the first commercial virtual machine system. As the name of the system implies, IBM’s VM was developed on the concept of a “virtual machine”. Although this concept has multiple meanings today, in the context of this paper and in parallel to IBM’s definition, the concept refers to “the creation of a number of different identical execution environments on a single computer, each of which emulates the host computer”. (“Virtual Machine”, Wikipedia) This gives VM the ability to “fake” each user into thinking they have an their own computer. Though each of its users believe that they have their own “private” machine, in actuality all the virtual machines are running on a single physical computer. One of the most important benefits of this concept is that users can run their own operating systems, and even run different operating systems at the same time. This allows advantages such as running a test version of a new operating system, while still running the older version of the operating system on a separate virtual machine, for debugging purposes. Additionally, it allows a smooth transition to the new OS without interrupting the system, which avoids any “down time”. This paper examines the IBM VM operating system, a time-sharing system that divides the resources and processing power of a single mainframe computer among multiple users. The paper will illustrate how the VM system utilizes the virtual machine concept, and will also go into detail about some of its features. The design and implementation of IBM’s VM system has allowed it to become a successful operating system that has withstood the test of time and is still widely used today, more than 30 years later.

Overview:

The VM operating system is composed of two main parts: the Virtual Machine (VM) and the Conversational Monitor System (CMS). The term “VM” is frequently used as shorthand for VM/CMS, which was originally called CP/CMS, where “CP” refers to the Control Program. The VM component of the system refers to the virtual machine operating system, which enables each user to think that they are using their own private computer. This is the part of the OS that makes use of the virtual machine concept discussed earlier. On the other hand, the Conversational Monitor System is an interactive single-user OS, that was specifically designed to run on top of the VM system. Each user runs a copy of CMS on their virtual machine, providing them with an environment for interactive program development and personal computing. It is interesting to note that the VM and CMS are actually two separate operating systems, which gives the VM/CMS system a more modular design. This architecture scheme allows the CMS to take the responsibility of dealing with the interaction with the individual users, while the VM does the work “behind the scenes” emulating the underlying hardware, to ensure that it appears to each user that they have their own machines, and that the virtual machines do not interfere with each other. In this paper, the term “VM” will refer to the entire VM/CMS system, which includes the Conversational Monitor System. ( “VM(Operating System)”, Wikipedia)

The IBM VM system was designed to run on big mainframe computers, specifically IBM’s successive line of mainframes: the System/360, System/370, System/390 and more recently, the zSeries. Similar to this line of mainframes, the VM system has also gone through a number of successive versions, each with distinct names. The VM/370 was the first commercial release of VM, which was designed to run on the System/370 mainframe. More recently was the z/VM, which is the most recent version of the VM system and is designed to run on IBM’s zSeries mainframes. (“VM/CMS”, Wikipedia) The version of VM that preceded the VM/370 was the CP-67, an experimental operating system designed for the System/360 by a group of IBM people at the Cambridge Scientific Center (CSC) in the mid-60s. The CP-67 was successful in creating the illusion of having multiple System/360’s by using virtual machines, but was not able to provide virtual memory to these virtual machines (virtual memory was incorporated into the VM/370). AT CSC, they also created the CMS single-user operating system that was designed to run on a virtual System/360; at that time CMS actually stood for the Cambridge Monitor System. (Varian, 1997) The VM system effectively divided the resources of a single IBM mainframe by emulating the interface to the underlying hardware to each virtual machine. This allowed the virtual machines to operate at a more abstract level in relationship to the hardware, which gave the VM the ability to “host” distinct operating systems, so that users could run different OS’s on different virtual machines concurrently.

The CP/CMS system was a break-through in operating systems because it introduced an entirely new kind OS that would provide each user with their own virtual machine. This achievement was a big deal at the time VM was in development, because personal computers were non-existent, and mainframe computers were very expensive. In a detailed description of the history of VM, Melinda Varian states that “the idea of a virtual machine system had been bruited about a bit, but it had never really been implemented … the idea of a virtual S/360 was new, but what was really important about their concept was that nobody until then had seen how elegantly a virtual machine system could be built, with really minor hardware changes and not much software.” (Varian, 1997) Through the development of the VM operating system, IBM pioneered the work in the area of virtual machines. The architectural separation between the Control Program and the CMS was one of the key designs in the VM system because it added to the overall simplicity and beauty of the system by giving it a more modular design than traditional operating systems. In the VM/CMS, “the CP concerned itself with user isolation, including paging memory and virtualizing I/O, while 360 operating systems, including CMS variants, could be developed safely in isolation.” (Vleck, 2000) By allowing the execution of different operating systems simultaneously in their own virtual machines, VM provided an excellent engineering environment to run and test new OS’s. In fact, IBM debugged new versions of the VM/370 by running them under existing versions of VM/370. Thus, the modular design of the IBM VM promoted the evolution of the system, which is much of the reason why it has enjoyed longevity and success.

Another reason why the IBM VM was a successful operating system was because it was initially developed experimentally by a small, diverse research and development group at Cambridge, with the later addition of developers from MIT’s Lincoln Labs and also from Union Carbide, an IBM customer that decided to run the CP-67 system and sent 2 of its system programmers to Cambridge to aid in the VM’s development. The VM did not go through formal product development, nor did it have schedules or budgets to meet. Initially, it was just a system being developed for practical use by a small group of organizations running the CM/CMS system; they had no idea that it would later become a commercial undertaking by IBM and evolve into a widely used OS. (Varian, 1997) In this sense, the development of the IBM VM can be compared with the fashion in which modern operating systems, such as LINUX, were developed. Many people developed LINUX non-commercially, in a collaborative effort without the bounds of budgets or schedules. This allowed it to be created in an environment that promoted experimental trial-and-error, learning, and new ideas: much like the way the initial versions of the VM operating system were created. Today the IBM VM system is running at hundreds of sites (with licensing fees being paid to IBM), and ironically, one of the newest innovations has been the idea of incorporating LINUX on the VM operating system, allowing hundreds of copies of LINUX to run simultaneously on different virtual machines. This idea is ideal for web servers, as well as other applications, because a system crash only affects a single virtual machine, while the overall system continues to run unaffected.

Processor Modes:

In a time-sharing system that divides the system’s resource, such as the VM/CMS, it is necessary the to maintain proper operation by “protect[ing] the operating system and all other programs and their data from any malfunctioning program”. (Silberschatz et al, 2003, page 43) For example, if a faulty program executed instructions that altered the data of another program, it could cause the system to lose the state of that program making it execute incorrectly. In VM system, it is especially important to provide security between the “guest” programs on the virtual machines; otherwise one error in a single program could potentially cause errors in all the other guest programs. This would be a disastrous result, so it is ideal to have a feature in the operating system that will provide robust security among the various programs and to maintain data integrity.

Operating systems can provide a solution to the problem by providing hardware support to differentiate between at least two modes of operation: user mode and monitor mode. In user mode the system deals with execution done on behalf of the user, while on the other hand, monitor mode deals with execution done on behalf of the operating system. IBM defines these states as Problem (user mode) and Privileged (monitor mode). (Hardy, 2003) Certain operation codes of the machine are designated as privileged instructions, and when in Privileged mode, these machine instructions are carried out normally. On the other hand, if the system is in Problem mode and privileged instructions are executed, the instructions are not obeyed, but rather cause the system to trap to privileged code. The privileged code then resumes in the privileged state with access to the state of the program that tried to execute the privileged instruction. (Silberschatz et al, 2003) This is a method to protect the system from instructions executed by application programs.

For the VM operating system, the concept of privileged mode is taken a step further because just as a real machine must execute in two states, a virtual machine must also have the ability to operate in a user mode and a monitor mode. A virtual machine that is in a privileged state is said to be in a “virtual privileged” state. When a VM is virtual privileged, the “real” machine, controlled by the Control Program (CP) is always in user mode, which ensures that the instructions executed by the VM cannot be malicious to the CP or any of the other virtual machines running. (Hardy, 2003) Therefore, the CP maintains integrity in the system by not only protecting itself, but also isolating each of the virtual machines from each other by guarding the data associated with each VM. This is an excellent example of how the VM’s modular design proved to be effective in its development.

In IBM terms, all other code besides the Control Program’s code is referred to as “guest code”. The CP runs all guest code while in user mode, making it similar to the operation of traditional operating systems – this leaves it unsusceptible to malfunctions in the system due to incorrect programs, as mentioned above. Each of the guest programs has specific virtual machine instructions that were meant to run in privileged mode and must follow the appropriate functions in response to these instructions relative to that particular VM. We refer to these special sets of instructions as virtually privileged instructions. (Hardy, 2003) These types of instructions are always trapped by the CP, which is in problem mode, so that it handles the appropriate functions to carry out with the hardware. This is how the CP protects itself and all the other virtual machines rather than allowing the virtual machine to do so. By incorporating virtually privileged instructions, the IBM VM successfully “simulates” a program interruption caused by a virtually privileged instruction, without the CMS operating system at the user level even knowing.

Multiprogramming/Multiprocessing:

In the VM operating system, the CPU is multiprogrammed between numerous virtual machines. Multiprogramming allows a system to keep many jobs in memory at the same time so that the CPU does not have to sit idle while it is waiting for a job to perform some task, such as an I/O operation. Each copy of the CMS run on the VM system provides direct communication between the system and the user via a command prompt, which means that it must wait to receive commands from the user via a keyboard before it can take any action. Multiprogramming is ideal for VM because humans are much slower than computers, so the CPU will waste valuable time if it has to wait for instructions from the user before it can continue. By allowing the system to multiprogram virtual machines against each other, VM allows the CPU to continue to perform productive work on other jobs while it waits for the user to interact. Furthermore, when we describe the VM/CMS system as a “time-sharing system”, we imply that “the CPU executes multiple jobs by switching among them, but the switches occur so frequently that the users can interact with each program while it is running”. (Silberschatz et al, 2003, p.10) This is important in maintaining the illusion of separate, “private” computers for each of the users on the system. The VM operating system uses time-sharing to appear to provide multiple interactive CMS environments simultaneously, when in reality it is multiprogramming the virtual machines running the CMS environments.

The VM is also a multiprocessing system. We refer to the concept of multiprocessing as the ability of using multiple concurrent processes in a system, rather than a single process at any particular moment in time. VM promotes multiprocessing by making use of a CPU scheduling scheme that divides up the resources of the “real” machine to create the illusion that the system’s users appear to have their own processors. The IBM VM was uses a symmetric multiprocessing (SMP) architecture to accommodate the multiprocessing feature. In the SMP architecture, each processor is treated as a symmetric, equal resource, and every processor runs a copy of the operating system concurrently. (Varian, 1997) The idea of multiprocessing in virtual machines is shown in the figure below.

Figure 1.1: Multiprocessing in a VM System

This figure is an adaptation of Figure 3.11: System models, in Chapter 3 of Operating System Concepts by Silberschatz. (Silberschatz, 2003, p.81) The figure shows a VM operating system with three distinct virtual machines running on, each of which has their own copy of the CMS system. The three processes are running simultaneously, giving each user the illusion of having their own processor, and without knowing the existence of any of the other processes. The virtual machine system acts as the “brains” of the system, and accomplishes multiprocessing by splitting up the actual physical resources, and providing three identical interfaces to the underlying hardware.

Process States:

An important design strategy to enforce security in the IBM VM system was the manner in which it would maintain process states. With the division of the operating system into many virtual machines and the Control Program, it was imperative to maintain the internal data of each of the virtual machines as well as the CP itself, which in turn defined their current states. To deal with this issue, the VM implements a locking structure to guarantee the integrity of the data associated with each separate process in the system. In the VM system, a virtual machine can make a supervisor (system) call to the Control program, but the CP is essentially the one that executes the functions related to these calls. This situation produces a potential conflict because many virtual machines may be making supervisor calls, but the CP must handle them one at a time because it must execute only one system call at a time while interacting with the underlying hardware.

VM uses a logical software lock to by associating a word of storage for each process to distinguish between a “locked” and “unlocked” state. If the word has a nonzero value, it is in the locked state, while on the other hand, a zero value represents the unlocked state. Only one process can obtain the locked state at a time, and when it does it has access to the resources it requires. While in a locked state, the process is equivalent to that of a “running” process state. The other processes that are still in an unlocked state remain in a “ready” process state while they are waiting to obtain a locked state. Those processes in the ready state will try to obtain the lock “by trying to replace a zero word value with a nonzero word value using the System/370 [or another system’s] COMPARE AND SWAP instruction …[as] the replacement occurs only if the current content of the word matches the zero value specified in the instruction”. (Holley et. al, 1979, p.54) If the process does not successfully obtain a locked state then it loops through repeated attempts to acquire the locked state until it does so; also called a “spin”. After a process with the locked state is finished executing, it has the content of its word of storage replaced by a zero, indicating the unblocked state. This is equivalent to the finished process entering a “terminated” process state, and it will free up the resources it was using for the next process to use.

Memory Management:

Though the experimental version CP-67 was successful in simulating multiple virtual System/360 machines, these virtual machines did not have virtual memory. At the time, VM used the virtual memory of the “real” machine, in order to imitate the presence of real memory for the virtual machines. Later, IBM released the successor of the CP-67, the VM/370, which advanced the IBM VM further by adding the simulation of virtual memory for each of the individual virtual machines. ( “VM(Operating System)”, Wikipedia) This was ironic, because at one time it was general knowledge that virtual machines could not be accommodated with virtual memory. The addition of simulated virtual memory, and also the ability to run another copy of the VM system under itself, made the VM/370 a truly “virtual” system.

Virtual memory is a memory management design feature that allows the system to run processes that do not have to be fully in physical memory. Since each process is only partially in memory, it allows programs that are larger than the computer’s physical memory to be run on the system. The operating system accomplishes this feat by separating logical memory from physical memory through the mapping of virtual memory addresses to actual physical memory addresses. IBM utilized the idea of virtual memory in the Dynamic Address Translation (DAT) feature of its System/360 Model 67 architecture. In the zVM Principles of Operation book, IBM states that DAT “provides the ability to interrupt the execution of a program at an arbitrary moment, record it and its data in auxiliary storage, such as a direct-access storage device, and at a later time return the program and the data to different main-storage locations for resumption of execution”. (zVM Principles of Operation, 2003, p.3-26) Using the DAT feature, the VM can provide “virtual storage” ( IBM’s name for virtual memory) which is made up of pages. The system keeps only the most recently referred of these pages in the actual physical main storage. If a user calls a page that is not in main storage at the time, that page is brought into main storage and replaces the page that has not been used in the longest period of time. Thus, VM uses a Least Recently Used (LRU) page-replacement algorithm. In the VM operating system, virtual storage is divided into segments of 64 kilobytes in size and pages that are each 4 kilobytes in size.

For VM to be able to provide each virtual machine with virtual memory, the CP must use its own DAT hardware to simulate translation hardware for each virtual machine. It does this by using three types of mapping tables, which are located in the RAM of the system that is responsible for the control of DAT. The article “Virtual Storage and Virtual Machine Concepts” from the IBM Systems Journal identifies the first two types of mapping tables when it says that “the tables of the control program in the V67 [a virtual Model 67 machine] indicating how its virtual addresses are to be translated into “real addresses” [first type] must be combined with CP-67’s tables indicating how the V67’s “real addresses” are to be mapped onto the main storage of the host Model 67”. (Parmelee et al, 1972, p.114) The resultant combined tables are called “shadow tables”, representing the third kind of mapping tables. In essence, a guest program will map a virtual address to a real address using the first table, then the CP maps this real address to another real address using the second table, and finally the shadow table will map the virtual address from the first table to the additional real address from the second table to combine the effects of the first 2 mapping schemes. This memory management design enables the IBM VM system to emulate virtual memory for its virtual machines.

Conclusion:

The IBM VM operating system incorporated the concept of virtual machines into an operating system to distribute the resources and processing power of a mainframe computer into many virtual machines. It provides users with the illusion of their own private, isolated computer including its own operating system, CPU, and even memory. The VM’s most valuable attribute is the ability to provide multiple diverse computing environments. With this feature, it is possible to run multiple distinct operating systems simultaneously, which provides many advantages. Some of these benefits include testing new versions of an operating system while still running an older version, allowing smooth transitions to new operating systems without any down time, and testing new application code on multiple OS platforms. Presently, there are may different operating systems that can be run under the VM system, including DOS, UNIX, MVS, MUSIC, and more recently, LINUX. The IBM VM’s design has allowed it to enjoy commercial and technical success, with hundreds of sights still running it today, three decades later.

Bibliography:

Hardy, N. “Short History of IBM’s Virtual Machines.” (2003). URL:

Holley, L., Parmelee, R., Salisbury, C., Saul, D. (1979) “VM/370 Asymmetric Multiprocessing.” IBM Systems Journal., 18, 47-70.

Parmelee, R., Peterson, T., Tillman, C., Hatfield, D. (1972). “Virtual Storage and Virtual Machine Concepts.” IBM Systems Journal., 11, 99-130.

Silberschatz, A., Galvin, P., Gagne, G. (2003). Operating System Concepts. New York, NY: John Wiley & Sons, Inc.

Varian, M. (1997). “VM and the VM Community: Past, Present, and Future.” URL:

“Virtual Machine.” Wikipedia. URL:

Vleck, T. (2000). “The IBM 360/67 and CP/CMS.” URL:

“VM/CMS.” Wikipedia. URL:

“VM (Operating System).” Wikipedia. URL:

(Operating_system)

zVM Architecture Principles of Operation.(2003). IBM Corporation. SA22-7832-02.

URL:

-----------------------

Process

Process

Process

kernel

kernel

kernel

VM3

VM2

VM1

Hardware

VM Implementation

Programming Interface

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download