----- VMESA FORUM appended at 22:10:27 on 90/09/07 GMT (by JPH at GDLVM7) -----
Subject: Storage-Key Facility
 
I have found a paragraph that has been approved for distribution as a
description of the Storage-Key Facility, an enhancement to the
interpretive-execution architecture which is required to be installed on
a machine IPLing the ESA feature of VM/ESA.  SKF is not new, and is used
by VM/XA when it is installed, but it was never before publicized because
VM never before required it.  Since many people have asked what SKF is,
I'm appending the description here.  I'm including an introduction of my
own since the SKF description assumes knowledge of the existing
architecture.  More information on the existing interpretive-execution
architecture can be found in SA22-7095, "IBM System/370 Extended
Architecture, Interpretive Execution".
 
When VM/ESA runs a V=V guest, it keeps track of two views of the
reference and change bits associated with each page of guest storage,
the guest view, and the host view.  The guest view is what the guest
thinks the bits are as a result of issuing key instructions and making
storage references.  The host view is the information needed by CP to
manage real storage, to control paging algorithms.  To illustrate
how these views can be different, consider the following sequence:
 
 HC,HR  GC,GR       (host-change, host-ref, guest-change, guest-ref)
 -----  -----
  0  0   0  0       Initial state
  1  1   1  1       After the guest stores into the page
  1  1   0  0       After guest issues SSK to set ref & change to zeros
 
In this example, CP needs to remember that the page has been changed
since it was paged in, even though the guest wants to consider it an
unchanged page.  In basic interpretive-execution architecture, the needed
information was kept in Reference-and-Change Preservation (RCP) areas.
When the machine interpreted a guest key instruction, it would update the
real key and the information in the RCP area.  The basic architecture,
however, would only do this if the page was resident in host storage when
the guest issued the key instruction.  For CMS, it was often the case
that the page was not resident, causing the instructions to intercept and
be simulated by CP, resulting in a performance degradation.
 
SKF description:
 
   Bit 0 of the RCP Area Origin field (bytes 96-99 of the SIE
   state description) controls the interpretive execution of the
   storage-key facility.  If the pageable-storage mode is
   specified (bit 4 of byte 3 of the SIE state description is
   zero), the storage-key facility is installed, and the
   storage-key facility control is one, then the RCP area is
   ignored and the area used to contain the reference-and-change
   information is the VM/ESA page-status table.  Without this
   facility, all guest ISK, ISKE, SSK, and SSKE instructions are
   treated as mandatory interceptions if the host has paged out
   the storage associated with the storage key that the guest is
   trying to access.  With the facility, the instruction is
   interpretively executed using information held in the VM/ESA
   page-status table.
 
My summary:  SKF has at least two advantages over basic architecture:
 
 1. Guest key instructions are interpreted by the machine even when
    the page is not resident, resulting in a performance improvement
    for CMS.
 2. RCP information is kept in VM/ESA's page-status tables, rather than
    separate RCP areas.  This simplifies CP code.
 
Jim Hennessy