HP OpenVMS Systems Documentation
Upgrading Privileged-Code Applications on OpenVMS Alpha and OpenVMS I64 Systems
2.3.3 Location of Process and System Working Set Lists
The base address of the working set list can no longer be found within the process PHD or the system PHD. To obtain the address of the process working set list, use the 64-bit data cell CTL$GQ_WSL To obtain the address of the system working set list, use the 64-bit data cell MMG$GQ_SYSWSL.
Note that pointers to working set list entries must be 64-bit addresses in
order to be compatible with future versions of OpenVMS Alpha after Version
Each working set list entry (WSLE) residing in the process or the system working
set list is now 64 bits in size. Thus, a working set list index must be interpreted
as an index into an array of quadwords instead of an array of longwords, and
working set list entries must be interpreted as 64 bits in size. Note that
the layout of the low bits in the WSLE is unchanged.
Due to the support for larger physical memory systems in OpenVMS Alpha Version 7.0, the PFN database has been moved to S2 space, which can only be accessed with 64-bit pointers. Privileged routine interfaces within OpenVMS Alpha that pass PFN database entry addresses by reference have been renamed to force compile-time or link-time errors.
Privileged code that references the PFN database must be inspected and possibly
modified to ensure that 64-bit pointers are used.
The offset PFN$L_REFCNT in the PFN database entry has been replaced with a different-sized offset that is packed together with other fields in the PFN database.
References to the field PFN$L_REFCNT should be modified to use the following macros (located in PFN_MACROS.H within SYS$LIBRARY:SYS$LIB_C.TLB).
As of OpenVMS Alpha Version 7.0, the offset PFN$L_PTE in the PFN database entry has been replaced with a new PTE backpointer mechanism. This mechanism can support page table entries that reside in 64-bit virtual address space.
References to the field PFN$L_PTE should be modified to use one of the following macros (located in PFN_MACROS.H within SYS$LIBRARY:SYS$LIB_C.TLB).
Note that pointers to PFN database entries must be 64 bits.
Prior to OpenVMS Alpha Version 7.0, the process header contained two internal arrays of information that were used to help manage the balance slot contents (specifically, page table pages) during process swapping. These two arrays, along with the working set list index (WSLX) and backing storage (BAK) arrays, no longer are required for page table pages.
The swapper process now uses the upper-level page table entries and the working
set list itself to manage the swapping of page table pages. A smaller version
of the BAK array, now used only for backing storage information for balance
slot pages, is located at the end of the fixed portion of the process header
at the offset PHD$Q_BAK_ARRAY.
The format of a free page table entry in S0/S1 space has been changed to use
index values from the base of page table space instead of the base of S0/S1
space. The free S0/S1 PTE list also uses page table space index values. The
list header has been renamed to LDR$GQ_FREE_S0S1_PT.
In order to support larger global sections and larger numbers of global sections in OpenVMS Alpha Version 7.0, the global page table has been moved to S2 space, which can be accessed only with 64-bit pointers.
Privileged code that references entries within GPT must be inspected and possibly
modified to ensure that 64-bit pointers are used.
The format of the free GPT entry has been changed to use index values from the base of the global page table instead of using the free pool list structure. The free GPT entry format is now similar to the free S0/S1 PTE format.
Note that pointers to GPT entries must be 64 bits.
As of OpenVMS Alpha Version 7.0, each process virtual addressing region is described by a region descriptor entry (RDE). The program region (P0) and control region (P1) have region descriptor entries that contain attributes of the region and describe the current state of the region. The program region RDE is located at offset PHD$Q_P0_RDE within the process's PHD. The control region RDE is located at offset PHD$Q_P1_RDE, also within the process's PHD.
Many internal OpenVMS Alpha memory management routines accept a pointer to the region's RDE associated with the virtual address also passed to the routine.
The following two functions (located in MMG_FUNCTIONS.H in SYS$LIBRARY:SYS$LIB_C.TLB) are available to obtain the address of an RDE:
2.4 Kernel Threads Changes
This section describes the OpenVMS Alpha kernel threads features that might
require changes to privileged-code applications.
The CPU$L_CURKTB field in the CPU databases contains the current kernel thread
executing on that CPU. If kernel-mode codes own the SCHED spinlock, then the
current KTB address can be obtained from this field. Before kernel threads
implementation, this was the current PCB address.
No changes are necessary to kernel-mode code that locks mutexes. All of SCH$LOCK*,
SCH$UNLOCK*, and SCH$IOLOCK* routines determine the correct kernel thread if
it must wait because the mutex is already owned.
Code that calls any of the scheduling routines that previously took the current PCB as a parameter must be changed to pass the current KTB. These scheduling routines are as follows:
Code that calls any of the scheduling routines that previously took the process PID as a parameter must be changed to pass the thread's PID. These scheduling routines are as follows:
2.4.4 New MWAIT State
A thread that is waiting for ownership of the inner-mode semaphore may be
put into MWAIT. The KTB$L_EFWM field contains a process-specific MWAIT code.
The low word of the field contains RSN$_INNER_MODE, and the upper word contains
the process index from the PID.
The system services dispatcher has historically passed the PCB address to
the inner-mode services. This is still true with kernel threads. The current
KTB is not passed to the services.
The ACB$L_PID field in the ACB should represent the kernel thread to which the AST is targeted. All other AST context is the same.
Inner-mode ASTs can be delivered on whichever kernel thread is currently in inner mode. ASTs that have the ACB$V_THREAD_SAFE bit set will always be delivered to the targeted thread, regardless of other-inner mode activity. Use extreme care if this is used. Attempted thread-safe AST delivery to a kernel thread that has been deleted is delivered to the initial thread.