Inactive pages are kept on a direct access storage device. If an
inactive page bas been changed at some time during virtual machine
execution, CP assigns it to a paging device, selecting the fastest such device with available space. If the page has not changed, it remains
allocated in its original direct access location and is paged into real
storaqe from there the next time the virtual machine references that
page. - A virtual machine program can use the DIAGNOSE instruction to
tell CP that the information from specific pages of virtual storage is
no longer needed; CP then releases the areas of the paging devices which
were assigned to hold the specified pages. Paging is done on demand by CP. This means that a page of virtual
storage is not read (paged) from the paging device to a real storage
block until it is actually needed for virtual machine execution. CP makes no attempt to anticipate what pages might te required by a virtual
.achine. While a paging operation is performed for one virtual machine,
another virtual machine can be executing. Any paging operation
initiated by CP is transparent to the virtual machine.
If the virtual machine is executing in extended control mode with
translate on, then two additional sets of segment and page tables are
kept. The virtual machine operating system is responsible for mapping
the virtual storage created by it to the storage of the virtual machine.
CP uses this set of tables and the page and segment tables created for
the virtual machine at logon time to build shadow page tables for the
virtual machine. These shadow tables Bap the virtual storage created by
the virtual machine operating system to the storage of the real
computing system. The tables created by the virtual machine operating
system may describe any page and segment size permissible in the IBM System/370. YM/370 provides both fetch and store protection for real storage. The
contents of real storage are protected from destruction or misuse caused
by erroneous or unauthorized storing or fetching by the program.
Storage is protected from improper storing or from both improper storing
and fetching, but not from improper fetching alone. When protection applies to a storage access, the key in storage is
compared with the protection key associated with the request for storage
access. A store or fetch is permitted only when the key in storage matches the protection key. When a store access is prohibited because of Frotection, the contents
of the protected location remain unchanged. On fetching, the protected
information is not loaded into an addressable register, moved to another
storage location, or provided to an I/O device. When a processor access is prohibited because of protection, the
operation is suppressed or terminated, and a program interruption for a
protection exception takes place. When a channel access is prohibited,
a protection-check condition is indicated in the channel status word (CSW) stored as a result of the operation. Part 2. Control program (CP) 77

When the access to storage is inhibited by the processor, and
protection applies, the protection key of the processor occupies bit
positions 8-11 of the PSW. When the reference is made by a channel, and
protection applies, the protection key associated with the I/O operation
is used as the comparand. The protection key for an I/O operation is
specified in bit positions 0-3 of the channel-address word (CAW) and is
recorded in bit positions 0-3 of the channel status word (CSW) stored as
a result of the I/O operation.
To use fetch protection, a virtual machine must execute the Set Storage Key (SSK) instruction referring to the data areas to be
protected, with the fetch protect bit set on in the key. VM/370 subsequently:
1. Checks for a fetch protect violation in handling privileged and
nonprivileged instructions.
2. Saves and restores the fetch protect bit (in the virtual storage
key) when writing and recovering virtual machine pages from the
paging device.
3. Checks fer a fetch protection violation on a write CCW (except for
spooling or console devices).
The CMS nucleus resides in a shared segment. This presents a special
case for storage protection since the nucleus must be protected and
still shared among many CMS users. In order to protect the CMS nucleus
in the shared segment, user programs and disk-resident CMS commands run
with a different key than the nucleus code.
The system operator may assign the reserved page frames option to a
single virtual machine. This option, specified by the SET RESERVE command, assigns a specific amount of the storage of the real machine to
the virtual machine. CP will dynamically build up a set of reserved
real storage page frames for this virtual machine during its execution
until the' maximum number "reserved" is reached. Since the pages of
other virtual machines are not allocated from this reserved set, the
effect is that most of the active pages of the selected virtual machine
remain in real storage.
During CP system generation, the installation may specify an option
called virtual=real. With this option, the virtual machine's storage is
allocated directly from real storage at the time the virtual machine
logs on (if it has the VIRT=REAL option in its directory). All pages
except page zero are allocated to the corresponding real storage
locations. In order to control the real computing system, real page
zero must be controlled by CP. Consequently, the real storage size must
be large enough to accommodate the CP nucleus, the entire virtual=real
virtual machine, and the remaining pageable storage requirements of CP and the other virtual machines.
The virtual=real option improves performance in the selected virtual
machine since it removes the need for CP paging operations for the
selected virtual machine. The virtual=real option is necessary whenever
programs that contain dynamically modified channel programs (excepting
those of OS ISAM and OS/VS TCAM Level 5) are to execute under control of CP. For additional information on running systems with dynamically
modified channel programs, see "Dynamically Modified Channel programs"
in "Part 1. Debugging with VM/370." 78 IBM VM/370 System Programmer's Guide