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
> > >
> >
> >
> > --
> > Jay Maynard
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to [email protected] with the message: INFO IBM-MAIN
> >
> >
> > ----------------------------------------------------------------------
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to [email protected] with the message: INFO IBM-MAIN
> >
>
>
> --
> Jay Maynard
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to