On Sat, 5 Mar 2022 at 19:48, Charles Mills <[email protected]> wrote: > > I guess I am unclear on the sequence of events involved. Serious question, > not an argument: > > I have an ordinary problem state program that attempts to access storage > that it does not have access to. Obviously a S0C4 is the result. Let's say > the address is a valid virtual address (but the storage key is wrong) and > the page representing that virtual address is paged out. What is the > sequence of events that leads to the S0C4? Does the OS have to page in the > page so the hardware can generate a S0C4? That seems inefficient.
[My interpretation of the PofO; yours may be different and/or just as good:] Keep in mind that pages (of virtual storage) don't have things like a storage key and change and reference bits. Only page frames (blocks of real storage) have that stuff. (Yes, there is the IVSK instruction, but that still ultimately deals with real storage, and will itself get a page fault if there is no valid translation to the real address of the page. I believe it exists to avoid the risk of an interrupt between LRA and ISK[E] that could otherwise arise.) So if the address is in a page that's paged out, the page table entry will be marked as invalid. This leads to a program interrupt 11 (page fault). If the virtual storage for that page is not allocated, then the program interrupt 11 will be converted into a S0C4 abend. If the page exists in a slot in a page dataset, z/OS will page it in and retry the failing instruction. If there is a key mismatch at that point it gets a program interrupt 4 (protection exception), and this is also turned into a S0C4 abend. So by this description, yes, the OS has to page in the page to discover the protection exception. But... If the Invalid bit is on in the page table entry, the other 63 bits are available for software use, and I imagine that z/OS keeps information there about the key and the status of the page in auxiliary storage, and so should be able to issue the S0C4 without having to do the page-in. But that's z/OS, not the architecture, and I don't know what it really does under those OCO covers. > And in any event, whatever the mechanism, why could not that mechanism > generate a condition code for this hypothetical new instruction rather than > a program interrupt? It could if the architecture defined a place to keep the key for the page. But as far as I know it doesn't. Tony H.
