User manual

Introduction
3
high-performance designs that can reorder memory access and affect the order in which memory changes
performed by one processor become visible on another. These differences do not matter as long as VAX
code uses proper synchronization, such as spinlocks or interlocked instructions to communicate between
parallel branches of the code, since VAX MP will issue appropriate memory barriers once VAX interlocked
instruction is executed. However there are pieces of VMS code that do not issue appropriate memory
barriers by executing interlocked instructions. Most importantly, these are PU and XQ drivers (drivers for
UQSSP MSCP disk/tape controllers and Ethernet DEQNA/DELQA controllers) that communicate with their
devices not only through CSRs but also by reading from and writing to shared control memory area –
control area shared by the device and CPUs and read from and written to asynchronously by both the
device and CPUs. PU and XQ driver do not (most of the time) issue memory barriers when accessing this
memory area, relying instead on stronger memory-consistency model of historically existing VAX
implementations that provide ordering of reads and writes to memory in the same order they were issued
in VAX instruction stream. When executed on top modern host CPUs, such VAX code would not work
properly and reliably since underlying memory access can be reordered by the host CPU at will, unless
memory barriers are issued – and such barriers are missing in VMS PU and XQ code. Therefore VSMP
installs patches in PU and XQ drivers to fix their memory accesses to the control memory regions shared
by the devices and CPUs, by providing required memory barriers that force proper ordering of memory
reads and writes.
Some other patches deal with the fact that VAX MP VCPU threads are idleable. On a real VAX, when VMS
is in idle loop, CPU will spin in idle loop executing it over and over again, until it finds that some work to
do had arrived. On VAX MP, VCPU threads do not have to spin in this situation, consuming host processor
resources for nothing. When VMS enters idle loop on a given VAX MP VCPU, this VCPU's thread instead of
spinning in the loop can go into hibernated state on host OS so as not to consume host processor
resources while idle. Some of the patches installed by VSMP are intended to support this capability,
including both going into idle sleep and then, on scheduler events, waking only the number of VCPUs
actually required for pending processes in computable (COM) state. When VMS scheduler detects there
are some processes in computable state, it will normally “kick” all of the idling CPUs off the idle loop and
let them reschedule themselves. VSMP install patches that will wake up not all of the idling VCPUs but
only actually required number.
One of the patches modifies XDELTA system debugger (if loaded) to let it properly handle multiprocessing
on VAX 3900. XDELTA has CPU-specific code that gets current processor's CPU ID, and since it sees VAX
MP as VAX 3900, it assumes the machine is uniprocessor and always uses CPU ID #0. The patch modifies
this code in XDELTA to actually read from CPU ID register.
One of VSMP patches fixes bug in SYS$NUMTIM system service where system time location
EXE$GQ_SYSTIME is accessed without properly acquiring HWCLK spinlock, which may result in incorrect
value being read, including totally corrupt value. This can happen even on a real VAX, but probability of
this corruption increases when VAX processor is simulated on present-day host CPUs with weaker
memory-consistency model, compared to the original VAX. Patch installed by VSMP provides appropriate
spinlock acquisition by SYS$NUMTIM when reading system time variable.
VSMP patches binary code of the system, and this code is of course version-dependent.
If VSMP is running on a version of OpenVMS that differs too much from 7.3 and if because of this VSMP
fails to find certain target patch area and install required patch, it refuses to load. VSMP LOAD command