User manual

Introduction

at boot time as uniprocessor. After successful bootstrap, VSMP load command is executed (this can be

done either manually from DCL prompt or from SYSTARTUP_VMS.COM). Once VSMP is loaded, it

reconfigures the system to multiprocessor by creating additional CPU descriptors inside VMS kernel and

exposing VAX MP multiprocessing capability to VMS. After this point, system can be operated in regular

way just as any VMS multiprocessor. CPUs created by VSMP are initially in inactive state, so the first step

would be start them with DCL command START /CPU.

Maximum number of configurable VAX MP virtual CPUs is limited by the number of host logical CPUs,

including hyperthreaded/SMT units. For example, commodity quad-core i7 based host machine allows

to configure and use up to 8 VAX MP virtual CPUs. It is not possible to run more VCPUs than the number

of LCPUs available on the host machine.

Maximum number of configurable VAX MP virtual CPUs is also limited by VMS maximum supported limit

of 32 processors. VAX MP had been successfully tested in 32-processor configuration on host machine (a

node in Amazon EC2 cloud) with two 8-core Xeon sockets, for a total of 16 cores, each multithreaded,

yielding a total of 32 LCPUs, which 32 VAX VCPUs are mapped to.

Guest OS requirements

Current release of VAX MP supports multiprocessing only for OpenVMS 7.3. Some earlier versions of

OpenVMS may run fine, but this had not been tested.

VAX MP dependence on OpenVMS version is mostly due to paravirtualization layer (VSMP) that is

loaded into VMS as a kernel-resident module.

VSMP loads VAX MP proprietory code into VMS kernel. This kernel-resident VSMP module takes over

VMS processor-specific CPULOA (SYSLOA650) routines.

VSMP LOAD command also dynamically modifies memory-resident copy of OpenVMS kernel and some

drivers loaded into main memory by installing about 30 patches to the running, in-memory copy of VMS

kernel and some VMS drivers. These patches are required to support multiprocessing.

VSMP does not change any files on OpenVMS system disk, it changes only in-memory copy of the loaded

system. Thus, other than just installing VSMP on system disk in a separate directory, no modifications to

OpenVMS system disk are required for VAX MP. OpenVMS system disk image remains intact and system

files are not modified for VAX MP. Only in-memory copy of OpenVMS is patched by VSMP. Hereafter,

these in-memory modifications are called “dynamic patches”, to oppose them to static patches of on-

disk files that VAX MP does not perform.

There is a number of technical reasons for VSMP dynamic patches:

Most of these patches are intended to address modern host machines’ weaker memory-consistency

model compared to VAX memory model. In VAX days there were no out-of-order instruction issuing,

speculative execution, write/read combining or collapsing, asynchronous multibank caches and other