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
A real disk device can be shared among multiple virtual machines.
virtual device sharing is specified in the VK/370 directory entry or by
a user command. If specified by the user, an appropriate password must
be supplied before gaining access to the virtual device. A particular
virtual machine may be assigned read-only or read/write access to a
shared disk device. CP checks each virtual machine input/output
operation against the parameters in the virtual machine configuration to
ensure device integrity. Virtual Reserve/Release support can be used to further enhance device
integrity for data on shared minidisks. Reserve/Release operation codes
are simulated on a virtual basis for minidisks, including full-extent
minidisks. For details on Reserve/Release su pport, refer to the VM/Jlg­ gng Determination Quide. The virtual machine operating system is responsible for the operation
of all virtual devices associated with it. These virtual devices may be
defined in the VM/310 directory entry of the virtual machine, or they
may be attached to (or detached from) the virtual machine's dynamically, for the duration of the session.
virtual devices may be dedicat.ed, as when mapped to a fully equivalent
real device; shared, as when to a minidisk or when specified as a
shared virtual device; or spooled by CP to intermediate direct access
In a real machine runninq under control of as, input/output
operations are normally initiated when a problem program requests as to
issue a START I/O instruction to a specific device. Device error
recovery is handled by the operating system. In a virtual machine, os
can perform these same functions, but the device address specified and
the storaqe locations referenced will both be virtual. It is the
responsibility of CP to translate the virtual specifications to real. Virtual I/O can be initiated by either processor; all real I/O requests must be executed by the main processor, and all I/O interrupts must be received on the main processor (the processor with 1/0 capability). Any I/O requests by the attached processor (the
processor without IIO capability) are transferred to the main processor.
In addition, the interrupts caused by the input/output operation are
reflected to the virtual machine for its interpretation and processing.
If input/output errors occur, CP records them but does not initiate
error recovery operations. The virtual machine operating system must
handle error recovery, but does not record the error (if SVC 76 is
used) Input/output operations initiated by CP and spooling), are performed directly
tr ans lat ion.
for its own purposes (paging
and are not subject to Virtual machines may access data on MSS mass storage
that virtual machine's standard 3330 device support.
faults, and associated asynchronous interruptions, are
the virtual machine in this situation.
volumes using ftSS cylinder
transparent to Part 2. ContrJl Program (CP) 79
Previous Page Next Page