D8KVIOIN then tests the IOBLOK status field to deter.ine the cause for
the interruption. If the block has been unstacked because of an
interruption, the field is zero. If the operation was not started, it
contains the condition code from the real SIO. Note: The VIRA should not see a real condition code 2 as the result of a 510, since channel-busy conditions are detected and reflected before any
real I/O operation is attempted.
A condition code of 3 is reflected virtual .achine and exit is taken
to the to the dispatcher. For a condition code of 1, the CSi status
field in the IOBLOK is examined to determine the cause for the CSi stored condition. The status is reflected to the virtual .achine and
various components of the virtual configuration may be freed, if the
status so indicates. For example, if the CSi status indicated both
channel end and device end, the operation was im.ediate and has completed. Thus, the CCi string (real) may be released and all virtual components marked available.
The CSi status returned for a virtual interruption must be tested in
the same manner, with the additional requirement that the status be
saved in the affected virtual I/O control blocks and that the CSt be
saved in the VDEVCSi field for the device causing the interruption. If
the unit check bit is on in the status field, the sense information saved in the associated IOERBLOK (pointed to by the IOBLOK) must be
retained so that a sense initiated by the virtual machine receives the
proper information.
In any case, when an interruption is received for a virtual device, a bit in the interruption mask, VCUDVINT, for the device;s control unit is
set to 1. The bit that is set is the one corresponding to the relative
address of the interrupting device on the control unit. For example, if
device 235 interrupts, the fifth bit in the VCUDVIRT mask in the VCUBLCK for control unit 30 on channel 2 is flagged. Similarly, the bit in the YCBCUINT in the affected YCBBLOK is also set; in this case, bit 3 in YCBBLOK for channel 2. If the interruption is a channel class interrupt (PCI or CE), the address of the interrupting unit (235) is stored in the VCBCEDEV field in the VCBBLOK. The final interruption flag is set in
the VMPEND field in the VMBLOK for the interrupted virtual .achine; the
bit set corresponds to the address of the interrupting channel. The
next time, the virtual machine is dispatched and becomes enabled for I/O. SCHEDULING I/O REQUESTS A task that requests an I/O operation must specify the device on which
the operation is to take place and must provide an IOBLOK that describes
the operation. Upon entry to DMKIOS, register 10 must point to the IOBLOK. The IOBLOK must contain at least a pointer to the channel
program to be started in IOBCAi and the address to which the dispatcher
is to pass control in IOBIRI. In addition, the flags and status fields
should be set to zero a If the operation is a control program function such as for spooling or paging, the entry point DftKIOSQR is
called. If the requester is the I/O executive (DftKVIOEX) attempting to start a virtual machine operation, the entry point DftKIOSQV is called and some additional housekeeping is done. In either
case, an attempt is made to find an available subchannel path from the
device to its control unit and channel. If an I/O unit in the path is
busy or scheduled, the IOBLOK for the request is queued to the control
block of the I/O unit. CP Iutroduction 1-91
Requests are usually queued first-in-first-out (FIFO), except those
requests: • To .ovable-head DASDs that are queued in order of seek address • That release the affected component after initiation (SEEKS and other
control com.ands) which are queued last-in-first-out (LIFO) from the
control block Whether or not the operation has been successfully started, the
caller requesting the I/O operation receives control froa DftKIOS. If a
free path to the device is found, the unit address is constructed and an SIO is issued. If the resulting condition code is zero, control is
returned to the caller; otherwise, the code is stored in the
requester's IOBLOK along with any pertinent CSW status, the IOBLOK is
stacked, any components that becoae available are restarted, and control
is returned to the caller.
Alternate path I/O scheduling is perforaed according to the following scheme: DftKIOS searches for an available path beginning with the primary path
to the device. If an available path to the device exists, the I/O request is started i •• ediately on the first available path to the
device.
If the device is busy or scheduled, the IOBLOK is queued off the RDEYBLOK. No alternate path processing is perforaed at the device level.
If the device is not busy, not scheduled, nor offline, an IOBLOK for
this I/O request is promoted upward to the RCUBLOK or RCBBLOK level in
search of an available path. If a busy or scheduled path is
encountered, an IOBLOK is queued to the real block and the search
continues for an available path. If more than one busy path is
encountered, multiple IOBLOKs are queued for the same I/O request. This is accomplished by creating aini IO-BLOKs for each busy/scheduled path
after the first. The priaary IOBLOK is queued off the first busy path
encountered. The aini IOBLOK is 16 bytes in length and consists of the
first two doublewords of the IOBLOK, which is the same as the current IOBLOK structure. The IOBLOK and associated mini IOBLOKs are chained in
a single-threaded queue by means of the IOBLINK field. The active IOBLOK pointer is not stored in the IOBLINK field until just prior to
the SIO. Zeros are stored in IOBLINK at entry to DftKIOSQR to indicate
no m1n1 IOBLOKs have been queued as yet. See Figure 11 for an exaaple
of mini IOBLOK queuing.
The last two words of the aini IOBLOK (IOBFPNT and IOBBPNT) are used
as the double-threaded queue pointers for the RCUBLOK/RCHBLOK from which
it is queued. A flag is set in the mini IOBLOK to identify it as a mini IOBLOK. Pigure 18 shows a saaple control block structure when mini IOBLOKs are queued.
1-92 IBM VM/310 System Logic and Determination--Voluae 1
Previous Page Next Page