Determining processor status without IPIs 725

Eric P.

so the cp67-mvt and the vm370-vs1 scenario they had some additional information about the virtual guest. the program status word (PSW) had virtual supervisor-problem state and some other indicators. when the virtual PSW was in (virtual) supervisor state .. you were pretty sure that the operating system was in the kernel ... and so it wouldn't do much good. It was only when the virtual PSW was in (virtual) problem state that you were reasonably sure the guest operating system was running in application space. there was also hints about whether or not the virtual PSW was enabled for (virtual) io interrupts or not, etc.

in the cp67-mvt case ... the mvt guest believed it was running "real" w-o virtual address space support. the mvt guest got reflected a psuedo page fault interrupt from the hypervisor ... which it treated like a need for mvt to suspend the current application and see if it could task switch.this whole processing increased the overhead of providing virtual machine simulation ... but it allowed a guest operating system to get higher thruput than it would have if it was blocked from end while the hypervisor handled a page fault on behalf of the virtual machine. note that virtual page fault handshaking was an optional feature that could be turned on-off for specific virtual machines.

it was a little more complicated in the vm370-vs1 case ... the vs1 guest could be running a virtual address space ... i.e.

1st level ... 370 real address space 2nd level .... vm370 providing virtual address space for what the virtual machine thot was the real address space 3rd level .... virtual machine providing virtual address space

there would only be an issue with regard to vm370 having a page fault for 2nd level virtual addresses ... which it could reflect to the virtual machine thru page fault handshaking.

the issue of running a page replacement algorithm under a page replacement algorithm is a configuration and load issue ... and can result in some pathelogical performance issues that many might believe to be inexplicable (w-o understanding some of the underlying buttumptions behind page replacement algorithms).

this was significantly mitigated in the vm370-vs1 scenario. vs1 was a minimal translation of earlier batch system to virtual address space environment. basically vs1 created a single virtual address space ... and then for the most part pretended it was running on a real machine with real storage of the size of the virtual address space (typical configuration was 4mbyte virtual address space size running on a real 370 with 512k bytes). in the page handshaking scenario ... vm370 might provide a 4mbyte virtual machine address space size ... and vs1 would define a single virtual address space where the size exactly matched the virtual machine storage size. in this scenario while vs1 was running with a single virtual address space ... it wasn't doing any paging (or page replacement) ... since the single virtual address space size and the virtual machine address size was the same.

this had several advantages ... besides avoiding the page replacement under page replacement scenario. vs1 used 2k page options that was originally selected for the smaller real storage 370 sizes originally introduced ... i.e. compacted better on really small real storage. vm370 used 4k page sizes ... which didn't compact as well on really small real storages ... but could cut the number of page faults in half (since twice as much was being transferred at a time) ... and was less of a "compaction" issue was larger and larger real storages sizes become available on 370.

a "large" 370-145 had 512k storage. vm370-vs1 handshaking was introduced in the same time as ecps support for virgil-tully (138-148 follow-on to 135-145). typical 370-148 had 1mbyte of real storage (twice a large 370-145).

the other issue was that i had exceedingly optimized the end-to-end pathlength for turning a page (the pathlength efficiency and accurracy of page replacement), as well as whole io pathlength, task switch overhead, etc.

so in addition to possibly cutting the number of page faults in half when vs1 let vm370 do its paging (using 4k pages instead of vs1 native 2k page sizes) ... my total pathlength for doing a page fault (whether 2k or 4k size) was possible 1-5th to 1-10th the total pathlength that it took a vs1 kernel to handle a page fault (whether 2k or 4k size). This 1-5th to 1-10th value is for straight 370 instruction comparison ... and doesn't include the additional kernel ecps microcode performance buttist done for vm370 on virgil-tully machines. If doing 1-2 the page faults, each one at 1-10th the path length ... that yields about 1-20th the overall pathlength. specifically on virgil-tully, the ecps microcode buttist might represent an additional improvement of 2-4 times ... say 1-40th to 1-80th.