Note: OS/MVT is IBM's classic batch operating system for the 360 and 370 mainframe line; TSO is IBM's original interactive timesharing system for the 360 and 370 machines, and CMS, originally the Cambridge Monitor System and now the Conversational Monitor System is a single user interactive operating system for the 370, originally developed to run under VM. The combination of VM (originally known as CP) and CMS offers a far superior timesharing environment to TSO, but many IBM users sill use TSO for compatability and because the resource requirements of TSO are somewhat more modest than those of the VM/CMS combination.It is noteworthy that the virtual machine offered to VM processes is a sufficiently accurate copy of the underlying hardware that VM can be run as a client under VM!
Each process running under VM has a private address space that behaves as if it was the physical memory of a 370 compatable mainframe. Each process running under VM has access to virtual input/output devices that have interface specifications that are compatable with standard IBM mainframe peripherals, and each process running under VM has access to a virtual memory management unit. Furthermore, while VM itself runs in privileged state, while all VM users run in non-privileged state, each user under VM has a virtual privilege state that controls whether that user may execute virtual privileged instructions.
Recalling that VM was originally implemented in the late 1960's, when the standard-input stream to a program usually came from a deck of punched cards, and when the standard-output stream was usually directed to a line-printer, VM was, and in fact, still is, frequently configured to provide resources such as virtual card-readers, card-punches and line-printers to each client, and the equivalent of a UNIX pipe under VM involves connecting one client's virtual card-punch to another client's virtual card-reader.
Note that the IBM System 360 and 370 architectures use a field of the processor status word (PSW) to indicate whether the current program is privileged or unprivileged, and note that the instructions that manipulate the PSW are themselves privileged.
Part A: Outline the structure of a privileged instruction trap fault handler appropriate for use in an operating system such as VM. Assume that all attempts to execute a privileged instruction by an unprivileged program are directed to a single trap-handler, and focus your attention on the problem of handling user attempts to execute input/output instructions for a very simple input/output device such as a keyboard, where the physical keyboard has a status register and a data register. (In fact, no peripherals I know of on the 360 and 370 were this simple, but ignore this fact). Furthermore, assume that the VM operating system has an internal FIFO queue from which data is to be taken for the virtual keyboard.
Part B: Extend your outline above to include the concept of a virtual PSW. If the user attempts to execute a privileged instruction while in virtual privileged mode, the instruction works as expected. If the user attempts such an operation in virtual user mode, the user state changes to virtual privileged mode and control is transferred to the user's privileged instruction trap fault handler.
Part C: Extend your outline above to include support for the instructions a user would use to change the contents of the virtual PSW.
Part D: Consider the problem of allowing each VM users to maintain a virtual memory-management-unit. So, in virtual privileged state, the VM user would execute with the virtual memory-management-unit turned off, but in virtual user state, the virtual memory-management-unit would be turned on.
Part E: Could the Mach kernel, plus some set of support programs running under the kernel, be used to support a VM style environment, that is, an environment which resembles the host machine in sufficient detail that the Mach kernel could be run, as an application, under that environment?
Each process has a virtual address space that is divided into pages, using a conventional memory management unit. Each page occupies n words of the address space. Each page of this virtual address space may have 3 states:
An object is a memory address space, where the first location is a pointer to the routine called when a user tries to read from a page referring to the object, while the second location is a pointer to the routine called when a user tries to write to a page referring to the object. The remainder of the address space for an object must contain the code for the read and write methods, along with any data required by the object.
The read routine of an object must return a value (the value that the user will see as the result of the read operation), and it takes, as a parameter, the address (from 0 to n) within the object and the number of bytes being read. The write routine for an object takes, as parameters, the address being written (from 0 to n), the value being written, and the number of bytes in that value.
Part A: Write code for a very simple class, the counter, with two methods: increment and inspect. A write to any location in a counter object adds the operand to the counter. A read from any location of the object returns the value of the counter.
Part B: Given that each object is represented by an address space, where page zero of the address space contains the pointers to the methods, what is the minimum number of pages required to implement a counter object, assuming that the pages containing the actual code are shared between all instances of the class.
Part C: Propose an appropriate user interface for objects in the class open-file, with methods read, write, lseek and close.
Part D: Given that a conventional MMU is used to implement this system, outline how the address-translation-fault service routine would operate, so as to detect and properly implement the semantics of user operations on objects.