On recent generations, the keys are kept in the memory units, and cached in the cache hierarchy. On some prior generations, keys were cached in the TLB. I don't remember offhand in which generation that changed.
On the 3090 machines, I remember the engineers referring to separate key arrays. Around 1990, the 3090S and 3090J machines were experiencing a higher rate of uncorrectable storage key errors, so they started keeping a backup copy of the keys in HSA, and the MVS machine check handler was enhanced to use a Diagnose instruction interface to retrieve the backup copy in the case of a key error on those machines. For 24/31 bit address space non-SQA/LSQA virtual storage, VSM keeps track of the original storage key and provides that to RSM. RSM keeps track of what the current key should be in the DAT leaf entry (PTE, STE, or RTE). VSM is not made aware of key changes via the RSM CHANGKEY macro. VSM is not involved or consulted about keys when virtual storage gets backed in real storage. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Joe Monk Sent: Wednesday, November 23, 2022 8:30 AM To: [email protected] Subject: Re: Storage protection keys I know this is super old information ... but given the discussion so far, it seems reasonable to at least apply the same concept ... "The storage-protect unit has a 64 x 8 monolithic storage protection stack that applies to main storage locations zero through 131,072 (in sequential blocks of 2,048 bytes). Additional stacks are provided in the CPU when main storage capacity extends from 131,072 bytes to 524,288 bytes. Above 524,288 bytes, storage protect is located in the Power Frame (03) and is a mix of 64 x 8 and 64 x 18 monolithic storage cards." http://www.bitsavers.org/pdf/ibm/370/fe/3145/SY24-3581-4_3145_Processor_Theory_Maintenance.pdf Joe On Wed, Nov 23, 2022 at 6:56 AM Jay Maynard <[email protected]> wrote: > Well, you have to store the key *somewhere* when the page is paged > out. But you're right, the page table entry isn't it. I don't know > what I was thinking. > > I'm sure that VSM maintains its own table of correspondence between > virtual storage addresses and storage key, so the key can be applied > to the page upon page-in, but I don't know the details. > > On Wed, Nov 23, 2022 at 4:12 AM Ian Worthington < > [email protected]> wrote: > > > Many thanks for that Jay. This would certainly seem the logical > > place to store it. > > > > I'm still a bit confused though. The pop section on Page-Table > > Entries (page 3-51 in the 13th edition...) does not mention this > > (though it does have a unused byte at the end). If the intention is > > to make the storage key unaddressable (p 3-9) and alterable only via > > SSKE (which, given the need to propagate it to the caches of all > > processers would seem make > sense) > > would it not be contraindicated to use this byte to keep it in? > > > > I'd love to see a paper or article which discusses how this is done, > > though, like cpu design, I appreciate it may well change from model > > to model. > > > > > > Best wishes > > > > Ian ... > > > > On Tuesday, November 22, 2022 at 05:28:37 PM GMT+1, Jay Maynard > > < [email protected]> wrote: > > > > They are held in the page tables and set in the hardware - in extra > memory > > that is not software accessible except through a few > > supervisor-level instructions such as SSK (set storage key) - when > > the page is assigned > to a > > real storage frame. > > > > On Tue, Nov 22, 2022 at 10:24 AM Ian Worthington < > > [email protected]> wrote: > > > > > I don't think the storage keys (and their friends) are held in the > > > page tables though. > > > > > > > > > Best wishes / Mejores deseos / Meilleurs vœux > > > > > > Ian ... > > > > > > On Tuesday, November 22, 2022 at 05:04:08 PM GMT+1, Jay Maynard > > > < [email protected]> wrote: > > > > > > Each page table entry has a byte associated with it that stores > > > the > key, > > > as > > > well as the referenced and changed bits. > > > > > > And yes, 4K page tables do soak up lots of memory, which is why > > > later > > OSes > > > use 1M or 2M pages. > > > > > > On Tue, Nov 22, 2022 at 9:22 AM Ian Worthington < > > > [email protected]> wrote: > > > > > > > Does anyone know where the storage protection keys are kept? It > seems > > > > that the processors maintain recent keys in the TLB to be > > > > accessed by > > the > > > > DAT, but where do they live when they're not in the TLB? > > > > Surely we > > need > > > > one byte per 4k page per address space, which could be quite a > > > > bit of storage, so I'm assuming this has to be above the bar > > > > now? I can't > see > > > any > > > > information in the pop about this. > > > > > > > > > > > > Best wishes / Mejores deseos / Meilleurs vœux > > > > > > > > Ian ... > > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
