HP OpenVMS systems documentation

With the kernel threads implementation, the address space for a process can be active on multiple CPUs at the same time. Any privileged code that creates or deletes process virtual address space "by hand" must do the proper invalidation across all CPUs. A set of macros have been created for BLISS, C, and MACRO-32 to facilitate translation buffer invalidation. The macros are as follows:

• TBI_DATA_64
• TBI_SINGLE
• TBI_ALL

Table 2-1 describes the arguments for the TBI_DATA_64 and TBI_SINGLE macros. Note that the difference between TBI_DATA_64 and TBI_SINGLE is that the former invalidates an entry from the data translation buffer only, while the latter invalidates an entry from both the data and the instruction translation buffers.

Table 2-1 Arguments for TBI_DATA_64 and TBI_SINGLE

Keyword	Value	Meaning
ADDR	= The virtual address to be invalidated. The address can be either a 64-bit VA or a sign-extended 32-bit VA. For MACRO-32, the address must be specified in a register.
ENVIRON	= THIS_CPU_ONLY	Indicates that this invocation of TBIS is to be executed strictly within the context of the local CPU only. Thus, no attempt is made whatsoever to extend the TBIS request to any CPU or other "processor" that might exist within the system.
	= ASSUME_PRIVATE	Indicates that this is a threads environment and that the address should be treated as a private address and not be checked. Therefore, in an SMP environment, it is necessary to do the invalidate to other CPUs that are running a kernel thread from this process. This argument is used for system space addresses that should be treated as private to the process.
	= ASSUME_SHARED	Indicates that this invocation of TBIS should be broadcast to all other CPUs in the system. ASSUME_SHARED is the opposite of THIS_CPU_ONLY.
	= LOCAL	This is now obsolete and generates an error.
	= anything other than the above	Forces the TB invalidate to be extended to all components of the system that may have cached PTEs.
PCBADDR	= Address of current process control block. Default is NO_PCB, which means that a PCB address does not need to be specified. The default is R31 for the MACRO-32 macros.	This argument must be specified if the address to be invalidated is process-private (either ENVIRON=ASSUME_PRIVATE or no keyword for the ENVIRON qualifier was specified).

Table 2-2 describes the arguments for the TBI_ALL macro.

Table 2-2 Arguments for TBI_ALL

Keyword	Value	Meaning
ENVIRON	= THIS_CPU_ONLY	Indicates that this invocation of TBI_ALL is to be executed strictly within the context of the local CPU. No attempt is made to extend the TBIA request to any CPU or other "processor" that might exist within the system.
	= LOCAL	This is now obsolete and generates an error.
	= anything other than the above	Forces the TB invalidate to be extended to all components of the system that may have cached PTEs.

2.4.8 New PCB/KTB Fields

Table 2-3 shows the new PCB and KTB fields as defined by PCBDEF.

Table 2-3 New PCB/KTB Fields

Field	Meaning
PCB$K_MAX_KT_COUNT	Maximum number of kernel threads
PCB$L_ACTIVE_CPUS	CPUs owned by this process
PCB$L_TQUANTUM	Per-user thread quantum
PCB$L_MULTITHREAD	Maximum thread count
PCB$L_KT_COUNT	Current thread count
PCB$L_KT_HIGH	Highest KTB vector entry used
PCB$L_KTBVEC	KTB vector address
PCB$L_IM_ASTQFL_SPK	Special kernel AST queue forward link (head)
PCB$L_IM_ASTQBL_SPK	Special kernel AST queue back link (tail)
PCB$L_IM_ASTQFL_K	Kernel AST queue forward link (head)
PCB$L_IM_ASTQBL_K	Kernel AST queue back link (tail)
PCB$L_IM_ASTQFL_E	Executive AST queue forward link (head)
PCB$L_IM_ASTQBL_E	Executive AST queue back link (tail)
PCB$L_INITIAL_KTB	Initital KTB, overlays KTB$L_PCB
KTB$L_PCB	PCB address, overlays PCB$L_INITIAL_KTB
KTB$L_FRED	Address of FRED block
KTB$L_PER_KT_AREA	Address of per-kernel thread data area
KTB$L_TQUANT	Remaining per-user thread quantum
KTB$L_QUANT	Remaining per-kernel thread quantum
KTB$L_TM_CALLBACKS	Address of thread manager callback vector

2.4.9 CTL$AL_STACK and CTL$AL_STACKLIM

The two arrays containing stack bounds information are now quadwords. The arrays are now CTL$AQ_STACK and CTL$AQ_STACKLIM and are still indexed by access mode. The entries are QUADWORDS.

The arrays pointed to by these two data cells represent only the stack pointers for the initial kernel thread. For a process with multiple kernel threads, the stack arrays are in the per-kernel thread data area. The address of this structure can be found using the KTB$L_PER_KT_AREA field. These fields are defined in PKTADEF. The initial thread has a permanent per-kernel thread, so no distinction is needed between the initial thread and other threads when accessing this data. Table 2-4 shows the stack arrays.

Table 2-4 Stack Arrays

Array	Meaning
PKTA$Q_STACK	STACK pointer array
PKTA$Q_STACKLIM	STACK limit pointer array

2.4.10 Floating-Point Register and Execution Data Blocks (FREDs)

The FRED is defined by FREDDEF. The KTB$L_FRED field in the KTB points to the FRED block. The section of the PHD that contains the HWPCB and floating-point register save area for the initial thread is identical to the layout of the FRED. Therefore, no distinction is needed between the initial thread and other threads when accessing this data.

2.5 Registering Images That Have Version Dependencies

The need for change in any image (including device drivers, as well as privileged applications linked against SYS$BASE_IMAGE.EXE) is normally detected by a system version check. That check is designed to prevent an application that may need change from producing incorrect results or causing system failures.

The version checks do not necessarily mean that the applications require any change. Compaq recommends that you perform some analysis to determine compatibility for privileged images before you run them on Version 7.0 systems.

OpenVMS Alpha Version 7.0 provides an Image Registry facility that may obviate the need for relinking images when you upgrade from previous versions of OpenVMS Alpha. The Image Registry is a central registry of images (including layered products, customer applications, and third-party software) that have version dependencies but have been identified as being compatible with the OpenVMS operating system software. The products in the registry are exempted from version checking.

The Image Registry facility has several benefits, particularly when you have only image files, not source or object files. In addition, it eases version compatibility problems on mixed-version clusters because the same images can be used on all nodes. It also simplifies the addition of third-party software and device drivers to the system.