Virtual Machine Hardware 351

John Savard

one of the original uses of distributed development with the internal network (the internal network had more nodes than the arpanet-internet from just about the beginning to sometime around mid-85) http;--www.garlic.com-~lynn-subnetwork.html#internalnet

was a project between science center

and endicott for 370 virtual machines with virtual memory support.

cp-67 was a virtual machine operating system running on 360-67. 370 was going to have virtual memory support .... while there was a large commonality between 360 and 370 instructions (although there were some new instructions in 370) ... the control registers and segment-page tables had different formats between 370-67 hardware virtual memory and 370 hardware virtual memory.

cp-67 already support "non-virtual memory" 370 virtual machines as well as 360-67 virtual machines. it was possible to run a copy of cp-67 in a virtual machine under cp-67 running on a real 360-67 (and run other operating systems under the virtual copy of cp-67).

the cp-67 kernel was modifed to provide a special 370 virtual machine .... which provided support for the new 370 instructions (not implemented on 360) as well as translation of 370 virtual memory tables into "shadow" 360 virtual memory tables.

another set of modifications were made to cp-67 so that it buttumed that it was running on a 370 real machine ... and it created-used 370 format tables (rather than 360-67 format tables).

there was another problem. the 370 virtual memory support had not been announced. The science center cp-67 system provided time-sharing service to numerous non-corporate employees ... including various BU, MIT, Harvard, and other students in the cambridge area. there was a big concern that any of these non-corporate employees might accidentally stumble across the 370 implementation support. as a result, it was decided that the version of cp-67 that provided 370 virtual machine support (as an option, in addition to regular 360 virtual machines) would only run in a 360-67 virtual machine and not on the real hardware (so it would be isolated from access by non-authorized individuals also using the same machine).

so the operation was:

360-67 real hardware cp-67-l on real hardware ... providing 360 and 360-67 virtual machines cp-67-h running in 360-67 vm ... provide 360, 360-67, 370 VMs cp-67-i running in 370 vm ... provide 370 VMs cms running in 370 vm

note that the cp-67-i kernel was in regular operation a year before there was the first 370 engineering processor running with hardware virtual memory support.

a story about when the engineers got the first 370 engineering processor with virtual memory support operational, they were interested to see if the cp-67-i kernel would run on the machine. one of the cambridge people went to endicott with a copy of the kernel. they booted the kernel on the machine and it failed. after a little investigation, it was determine that the engineers had made a mistake in implementing some of the 370 virtual memory support. introduced with 370 were the "b2" opcodes ... and two of the new "b2" opcodes, were RRB (reset reference bit) and PTLB (purge table lookaside buffer). the engineers had reversed the opcode implementation for the two instructions. The cp-67-i kernel was patched to reverse the opcodes to correspond with what was implemented in the hardware and the kernel then booted and ran succesfully.

misc. past postings on 370 virtual machine effort listings future than modern crap ! virtualization in general