The Origin of the VM/370 Time-Sharing System (1981) [pdf] | Hacker News Reader

The Origin of the VM/370 Time-Sharing System (1981) [pdf]

lass.cs.umass.edu

47 pointstjalfi13 comments

In 1992, I worked for a company that had been founded by Les Comeau (one of the VM/370 authors mentioned in references 8/10/11). Because of that, and because I'd worked in some similar technical areas at my previous job, I was absolutely delighted to find that my (not yet) father-in-law had copies of some of those documents, with handwritten notes by the authors. Seeing this reminded me that I need to do something to make sure those get scanned and not lost. It truly was an under-appreciated precursor of many things we now take for granted.

“Some people claim there is a Time Sharing system that runs on OS/370, but after careful study I have come to the conclusion that they were mistaken.”

https://www.pbm.com/~lindahl/real.programmers.html

I haven't had the opportunity to read all of this document, but the thing I love the most so far is that it explains the history of what led up to the birth of the OS:

"With larger memories and independent I/O operation came the possibility of more efficient machine utilization. A portion of the machine could be dedicated to the programs which assisted in machine operation, the operating system. As a result, overall productivity of the system increased."

The author succinctly shows how we went from calculators to hardware with an OS. A wonderful explanation.

I kind of miss MULTICS, sure Unix/Linux..plan9? Are smaller lighter and more maintainable, but multics had features every single unix-like misses until today.

If you wanna try out MULTICS:

https://ban.ai/multics/

But they are offline ATM don't know why...

Or with the emulator (DPS8-M):

http://ringzero.wikidot.com/

Including a more secure systems programming language.

You can download and run your own Multics system under emulation:

https://multicians.org/sim-inst.html

The website will be back online soon; the system can be accessed ssh dps8@m.trnsz.com

Nice! Thank you very much for that!

VM/370 is the original virtualization system that later inspired VMware and all the others.

From the paper:

> A key concept of the CP/CMS design was the bifurcation of computer resource management and user support. In effect, the integrated design was split into CP and CMS. CP solved the problem of multiple use by providing separate computing environments at the machine instruction level for each user. CMS then provided single user service unencumbered by the problems of sharing, allocation, and protection.

I think we've lost this concept: We run Multics-like OSes as guests under Xen, not CMS-like.

> As an aside, the MULTICS system [13] of M.I.T.’s Project MAC and CP/CMS were both second-generation systems drawing heavily on the CTSS experience with very different architectural results.

And Unix is fundamentally of the Multics mold.

Another thing I want to comment on:

> The design of System/360, in order to facilitate the multiplexed execution of several jobs in a scheduled job environment, provided two instruction execution states: privileged and problem. The instructions available in problem state are those commonly used by application programs. They are innocuous to other programs within the same machine and can be safely executed. However, privileged instructions affect the entire machine as well as report its status. As they are encountered in problem state, the machine blocks their execution and transfers control to a designated program. When using CP, each virtual machine program is actually executed in problem state. The effects of privileged instructions are reproduced by CP within the virtual machines.

All privileged instructions faulting to the hypervisor is a basic requirement for efficient virtualization in the Popek & Goldberg virtualization requirements.

https://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualizat...

(It's nice to know what things are called if you want to do further research.)

Another interesting little note:

> For example, a piece of CP might be implemented within hardware to extend machine capability. Users of virtual machines and their operating systems would see no change in this function except possibly in cost or speed. Conversely, CP might simulate a new hardware feature to be tested. Performance might be poor, but programs using this feature could be run. This was done within IBM to prepare System/370 programs using a System/360.

Moving features from the hypervisor to the hardware is an interesting concept.

> The System/370 virtual machine can be in basic or extended control mode. Basic control does not include the virtual memory hardware. This type of machine is used by CMS and other operating systems that do not themselves utilize the address translation hardware. Extended control mode is selected when an operating system that controls virtual memory, such as CP or OS/VS, is executed in a virtual machine. This might be the case when a new version of CP is to be tested.

That's right: Running a hypervisor as a guest of another hypervisor, possibly to debug a newer hypervisor in a safe (and potentially gimmicked?) environment which is nevertheless exactly like running on bare hardware. Is that possible with non-VM hypervisors on commodity hardware? Or is it another idea we've lost?

Or is it another idea we've lost?

It's another idea we've lost. You can run VM on VM on VM... Wikipedia has a good article on why this doesn't work well with x86.[1]

[1] https://en.wikipedia.org/wiki/X86_virtualization

> Is that possible with non-VM hypervisors on commodity hardware? Or is it another idea we've lost?

It's possible. For example, I run ESXi on top of VMware Workstation.

There can be caveats and limitations. For example, Hyper-V cannot be nested on AMD CPUs, although I believe MS is working on this. This creates problems for running things like WSL2 inside a VM.

https://share.confex.com/share/124/webprogram/Handout/Sessio... Seems a good modern intro

Reply on news.ycombinator.com