AVM/EF (Advanced Virtual Machine/Extended Facilities) was an operating system (hereinafter “OS”) that controlled Fujitsu’s virtual computer (VM: Virtual Machine) system. It was announced in June 1982. AVM/EF achieved a small, 5 to 15% overhead (increase ratio of the CPU time of the real computer to the CPU time on a virtual computer) by using a high-speed VM mechanism in the hardware, and provided a high-performance virtual computer system. In June 1989, AVM/EX (Advanced Virtual Machine/Extended) was announced. AVM/EX used an extended VM mechanism that harmonized with the new architecture EXA (EXtended Architecture) of the M series, and reduced the overhead to as little as 1/3 of that of AVM/EF.
The following describes the brief history of the OSs for Fujitsu’s virtual computers, the functions of the OSs for virtual computers and the effects of adopting a virtual computer.
1. Brief history of the OSs for Fujitsu’s virtual computers
Fujitsu started shipping AVM (Advanced Virtual Machine) as the OS for virtual computers for the FACOM M series in 1980, mainly for large M series computers. AVM used an AVMA (AVM Assist) function of the hardware but simulation results indicated that it had a large overhead.
To solve this problem, Fujitsu developed a high-speed VM mechanism aimed at drastically reducing the overhead in the FACOM M-300 series general-purpose computers. As a result of utilizing this high-speed VM mechanism and developing a new function of using channel exclusively for virtual computers (exclusive channel function), Fujitsu was able to announce in June 1982 AVM/EF, which drastically reduced the overhead of the OS (the overhead of AVM/EF with the super-large computer FACOM M-380 model group was 5 to 15%).
Fujitsu implemented in higher machines of the M-700 series the extended architecture EXA (EXtended Architecture), which was developed by extending the previous M series architecture and adding a system storage unit (SSU), an extended channel mechanism (ECF) and an extended VM mechanism (EVM). In June 1989, the company announced AVM/EX (Advanced Virtual Machine/Extended), which supported the extended architecture as a virtual computer OS. AVM/EX used the extended VM mechanism of the hardware and reduced its overhead to as little as 1/3 (1/2 on average) of that of AVM/EF.
Fujitsu started shipping AVM (Advanced Virtual Machine) as the OS for virtual computers for the FACOM M series in 1980, mainly for large M series computers. AVM used an AVMA (AVM Assist) function of the hardware but simulation results indicated that it had a large overhead.
To solve this problem, Fujitsu developed a high-speed VM mechanism aimed at drastically reducing the overhead in the FACOM M-300 series general-purpose computers. As a result of utilizing this high-speed VM mechanism and developing a new function of using channel exclusively for virtual computers (exclusive channel function), Fujitsu was able to announce in June 1982 AVM/EF, which drastically reduced the overhead of the OS (the overhead of AVM/EF with the super-large computer FACOM M-380 model group was 5 to 15%).
Fujitsu implemented in higher machines of the M-700 series the extended architecture EXA (EXtended Architecture), which was developed by extending the previous M series architecture and adding a system storage unit (SSU), an extended channel mechanism (ECF) and an extended VM mechanism (EVM). In June 1989, the company announced AVM/EX (Advanced Virtual Machine/Extended), which supported the extended architecture as a virtual computer OS. AVM/EX used the extended VM mechanism of the hardware and reduced its overhead to as little as 1/3 (1/2 on average) of that of AVM/EF.
2. Functions of the OSs for virtual computers
CP (Control Program), which was the control program for AVM, created a virtual computer that was functionally equivalent to the real computer by dividing the real computer resources, reconfiguring them and simulating the functions of the real computer. The computer resources of the virtual computer (hereinafter “VM”) were created using CP in the following manner:
CP (Control Program), which was the control program for AVM, created a virtual computer that was functionally equivalent to the real computer by dividing the real computer resources, reconfiguring them and simulating the functions of the real computer. The computer resources of the virtual computer (hereinafter “VM”) were created using CP in the following manner:
(1) Virtual console
The system console unit of VM was called a virtual console. CP simulated IPL and other functions of the real computer’s console through CP commands from a virtual console such as a character display device.
The system console unit of VM was called a virtual console. CP simulated IPL and other functions of the real computer’s console through CP commands from a virtual console such as a character display device.
(2) Virtual CPU
The CPU of VM was called a virtual CPU. CP created a virtual CPU by allocating the calculation time of the real CPU to each VM based on the CPU distribution.
In AVM, CP simulated all actions including the execution of privileged instructions and interrupt action with the virtual CPU. However, with AVM/EF and AVM/EX, Fujitsu introduced the modes for identifying whether the CP was operating (host mode) or the VM was operating (guest mode), and added new mechanism, that allowed the hardware to directly execute instructions, to the high-speed VM mechanism and the extended VM mechanism. Although the extent to which the hardware directly executed instructions differed between the high-speed VM mechanism and the extended VM mechanism, this added hardware mechanism contributed to reduction of the overheads of AVM/EF and AVM/EX.
AVM/EX ensured high flexibility and reliability of operation by supporting the VMs of both the M architecture and the EXA architecture, and by allowing the VMs to share all CPUs within the system or a certain VM to use them exclusively.
The CPU of VM was called a virtual CPU. CP created a virtual CPU by allocating the calculation time of the real CPU to each VM based on the CPU distribution.
In AVM, CP simulated all actions including the execution of privileged instructions and interrupt action with the virtual CPU. However, with AVM/EF and AVM/EX, Fujitsu introduced the modes for identifying whether the CP was operating (host mode) or the VM was operating (guest mode), and added new mechanism, that allowed the hardware to directly execute instructions, to the high-speed VM mechanism and the extended VM mechanism. Although the extent to which the hardware directly executed instructions differed between the high-speed VM mechanism and the extended VM mechanism, this added hardware mechanism contributed to reduction of the overheads of AVM/EF and AVM/EX.
AVM/EX ensured high flexibility and reliability of operation by supporting the VMs of both the M architecture and the EXA architecture, and by allowing the VMs to share all CPUs within the system or a certain VM to use them exclusively.
(3) Virtual main memory
The main memory of VM was called virtual main memory. There were two ways for achieving virtual main memory. One was to allocate a continuous area of the main memory (real main memory) to each VM as the exclusive virtual main memory; there were two area types: a V = R (Virtual = Real) area and a domain area. The second way was to allow the paging area of the main memory (real main memory) to be shared as the main memory of multiple VMs using a demand-paging mechanism.
In the case of the domain area, in order to obtain the actual main memory (real main memory) address of the virtual memory space of VM (level 3 in the figure), it was necessary to add the initial address of the main memory (level 1 in the figure), to which the virtual main memory itself was allocated, in addition to the address of the virtual main memory (level 2 in the figure) where the virtual memory (level 3 in the figure) space of VM was mapped. With AVM, the overhead of the OS was heavy because the VM system rewrote the real address in an address conversion table generated by the VM system. For the high-speed VM mechanism and the extended VM mechanism, the company introduced a register that indicated the top address of the main memory (real main memory) part which allocated to a VM, in order to allow the system to add this registered value quickly when converting the address. This eliminated the table rewriting work from AVM/EF and AVM/EX, and drastically reduced the overhead.
The main memory of VM was called virtual main memory. There were two ways for achieving virtual main memory. One was to allocate a continuous area of the main memory (real main memory) to each VM as the exclusive virtual main memory; there were two area types: a V = R (Virtual = Real) area and a domain area. The second way was to allow the paging area of the main memory (real main memory) to be shared as the main memory of multiple VMs using a demand-paging mechanism.
In the case of the domain area, in order to obtain the actual main memory (real main memory) address of the virtual memory space of VM (level 3 in the figure), it was necessary to add the initial address of the main memory (level 1 in the figure), to which the virtual main memory itself was allocated, in addition to the address of the virtual main memory (level 2 in the figure) where the virtual memory (level 3 in the figure) space of VM was mapped. With AVM, the overhead of the OS was heavy because the VM system rewrote the real address in an address conversion table generated by the VM system. For the high-speed VM mechanism and the extended VM mechanism, the company introduced a register that indicated the top address of the main memory (real main memory) part which allocated to a VM, in order to allow the system to add this registered value quickly when converting the address. This eliminated the table rewriting work from AVM/EF and AVM/EX, and drastically reduced the overhead.
