LOCKING To provide system integrity, VK/370 attached processor support is
designed around one global system lock, a VKBLOK local lock, and several
system local locks for specifically identified queues or .odules.
All of the control program runs under the global system lock except
specifically identified paths. If the lock cannot be obtained, the
function is deferred by storing the necessary information in the VKBLOK appehdage and stacking that VKBLOK for later processing. That processor then takes a special unlocked path through the dispatcher to dispatch a
new virtual machine. In some situations the processor cannot defer the requested function and spins on the lock until it becomes available.
To ensure system integrity along
local locks have been defined. These
are held for short periods of time.
the special unlocked paths, various
locks are basically spin locks and
Each VKBLOK contains one lock, called VMLOCK, which is used by routines
that need to serialize certain virtual machine related resources. These
resources include the following:
1. Any unlocked or unshared pages belonging to the virtual machine.
2. Any of the unshared translation or backing store tables defining
the address space of the virtual machine.
3. Certain fields of the VKBLOK that are modified by routines that do not hold the system Some of these fields are V!PSW, VKGPBS, and VKBSTAT. The dispatcher obtains the VKBLOK lock before a virtual .achine is
dispatched and also before a CP request or an I/O request is unstacked. When a virtual machine is dispatched, the VKBLOK address of this virtual machine is saved in the processor's PSA in the field BUNUSEB. Nor.ally
this virtual machine is also unlocked by the dispatcher when it is
entered after an interrupt handler has finished processing. When BUNUSEB is still locked, the PSA field LASTUSEB is equal to BUNUSER. When BUNUSEB is unlocked, LASTUSEB is set to ASYSVK. When a CP request or an I/O request is unstacked, the associated
virtual machine is locked and the VKBLOK address is placed in register
11. When the dispatcher is entered after a CP request or an I/O request
has been serviced, the virtual .achine whose VMBLOK address is in
register 11 is locked and will be unlocked by the dispatcher. This
virtual machine may not be the same virtual .achine that was locked when
the CP request or the I/O request was unstacked. CP Introduction 1-173 I

A CP routine must lock another virtual machine for any of the
following reasons:
1. The routine, or a routine it calls, accesses any unshared page of
the virtual machine.
2. The routine, or a routine it calls, alters any field of the VMBLOK that is serialized only by the VMBLOK lock.
3. The routine, or a routine it calls, could be interrupted and an
exit taken to the dispatcher.
The original YMBLOK lock must be released before gaining the new
lock.
Figure 23 shows the modules that obtain the VMBLOK lock for a virtual
machine other than the one requesting the service.
There are situations when a CP routine may access a virtual machine without locking it. If the CP routine, or any routine it calls, is only
altering VMBLOK fields that are serialized by the system lock, locking
the virtual machine is not necessary. For example, to process the SET PRIORITY command for a virtual machine, locking the virtual machine is
not necessary since the altered VMBLOK field, VMUPRIOR, is serialized by
the system lock. But to process the SET FAVORED com.and, locking the
virtual machine is necessary since some of the V!BLOK fields altered,
such as VMRSTAT, are only serialized by the VMBLOK lock. DMKLOKFR DMKLOKRL DMKLOKTR DMKLOKDS Free Storage Lock
Run List Lock
Timer Request Queue Lock
Dispatcher Queues Lock CPEXBLOK Queue Lock
deferred execution blocks
processor related blocks
IOBLOK/TRQBLOK Queue Lock
These are system spin locks that are held for very short periods of time. The control program code that runs without the global system lock must manipulate these queues and these locks insure system integrity
along the unlocked paths.
If you have user-defined areas that are used by more than one virtual
machine and you need to serialize their use, you will need to define
your own locking conventions. You can use the LOCK macro to obtain and
release a PRIVATE lock. VML370 has details on
how to code the LOCK macro.
MACHINE CHECK HANDLER IN ATTACHED PROCESSOR A machine check interrupt is initially handled without the global system lock. DMKMCH determines if the error requires system termination,
virtual machine termination, or simply recording and continuation. If
the system was in a wait state or a virtual machine was in control and
the system is not to be terminated, the machine check handler requests
the global system lock with the defer option. If the lock can be
1-114 IBM YM/370 System Logic and Problem Determination--Voluae 1