[email protected] (Paul Gilmartin) writes: > That matches my old recollection of an Old Timer's recounting > his astonishment at having read a dump in which a Protection > Exception appeared to have been taken on a fetch instruction. > > I believe (with no good evidence) that it was controlled by > a bit in the page key. It may have been model-dependent. > A matching PSW key always allowed read-write access; a > different PSW key might have either no access or read-only > access depending on the bit's setting. > > Truly the Bad Old Days, when there was no privacy enforced > between jobs. And IBM OS technology has always trailed the > hardware technology. To wit, nowadays, the absence in z/OS > of complete support for 64-bit virtual. (The less said of > COBOL the better; it's not part of the OS.) > > Jim Mulder's explanation is most plausible; at some point > there may have been understandable reluctance to load user > code in key 0, only partly because there would have been no > way to guarantee confidentiality of such code.
cp67 had used games with storage protect key to provide integrity for cms shared pages (i.e. the same physical page appearing in multiple different virtual address spaces). It was a real ugly hack because cp67 had to fudge both the psw key that cms ran in as well as the storage keys (so no cms virtual machine could modify shared pages taking out other virtual machines). in the move to vm370, part of the original 370 architecture was segment protection (bit in the segment table entry) and cms was reorganized so that it shared pages were in 4k page, 64kbyte segments (370 had 2kbyte & 4kbyte page options as well as 64kbyte and 1mbyte segment options). however, 370/165 was starting to schedule slip with retofitting virtual memory hardware to the machine ... and in escalation meetings, it was decided to drop several features from 370 virtual memory ... including segment protect. As a result, all the other models that had already implemented full 370 virtual memory had to go back and remove the dropped features ... and any software written to use the dropped features had to be redone. This included the support for cms shared segments and returning to the ugly cp67 hack for protecting shared pages. during the FS period (when company was shutting down 370 work), I continued to work on 370 ... moving a bunch of cp67 enhancements to vm370 base and doing lot more stuff like page-mapped filesystem (avoiding lots of the performance shortcomings of the tss/360 and paged mapped stuff being worked on for FS) as well as significantly extended shared segment capability. some old email http://www.garlic.com/~lynn/2006v.html#email731212 http://www.garlic.com/~lynn/2006w.html#email750102 http://www.garlic.com/~lynn/2006w.html#email750430 with the death of FS, there was mad rush to get stuff back into the 370 product pipelines (the dearth of products during the FS period is also credited with giving the clone processor companies market foothold). some past posts http://www.garlic.com/~lynn/submain.html#futuresys This resulted in decision to release bits & pieces of stuff that i was distributing in csc/vm to internal datacenters (one of my hobbies was production systems for internal datacenters). A variation was some of the expanded shared segment stuff that I had done. Somebody had come up with hack for vm370 version 3 that eliminated the storage key hack ... allowing VMA microcode assist to be used with CMS (LPSW VMA microcode didn't have the rules for the storage key hack). An executing cms virtual machine could now modify shared pages ... so to fence the effect ... on every task switch, all shared pages were scanned to see if they had been modified, if they had, they were unshared, and unmodified shared page was fetched from disk. The story was with single shared 16page segment, the overhead of scanning 16 pages for modification on every task switch was less than the performance gain from being able to use VMA with CMS. The problem was that the inclusion of some of my shared segment enhancements ... also in version 3 ... increased the number of shared pages to be scanned on every task switch, invalidating the trade-off of better performance with VMA. I repeatedly pointed this out ... but eventually they came back and said that they couldn't drop the VMA use for CMS (reverting back to the cp67 storage key hack) ... because salesmen had pre-announced the VMA CMS use to 370/168 vm370 customers who had ordered VMA and paid substantial amount of money. The company couldn't go back and tell those customers that it had all been a mistake (and what they had paid for 370/168 VMA was waste of money). misc. past posts mentioning paged-map work http://www.garlic.com/~lynn/submain.html#mmap -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
