VM Data Spaces

z/VM uses an extension to the interpretive-execution facility called VM Data Spaces to provide data sharing services to application programs running in different virtual machines. These services are available to applications that run in XC virtual machines.

CP gives a virtual machine a primary address space when the user logs on to the z/VM system. After logging on, the XC virtual machine user may create other address spaces (called data spaces) and, if desired, share them with other logged on users. VM Data Spaces provide increased storage addressability and can move the burden of I/O from an application to the CP paging subsystem. The use of VM Data Spaces also extends the concept of sharing data. This has two chief advantages:

  1. It reduces storage requirements. One copy can be shared among many virtual machines instead of a copy per virtual machine.
  2. It reduces the need to transfer data by IUCV, APPC/VM, or some other communication vehicle.

CP macros can be used to create and work with data spaces. See z/VM: CP Programming Services. The CMS Callable Services Library (CSL) also provides an interface to VM data spaces from high-level languages.

The XC virtual machine mode is used for exploitation of VM Data Spaces. For non-XC mode virtual machines, DIAGNOSE X'248' (Copy to Primary function) can be used to move data from a data space to the virtual machine's primary address space. The Callable Services Library (CSL) provides an interface with high level language support.

Minidisk Mapping extends the concept of applications using storage and letting CP handle the real I/O. This function provides a means of associating minidisk data with VM data spaces. One or more minidisks can be mapped to one or more data spaces. An application references the data simply by referencing the corresponding storage location in the data space. The real I/O is handle by the CP paging subsystem, which provides efficiencies.

Some initial setup work is required to establish the mapping rules. This is managed by MAPMDISK, a CP macro. Since virtual storage is volatile, management for integrity must be considered. The SAVE function provides a means of forcing or committing the data to the non-volatile DASD where the minidisk resides. Minidisks that are to be referred to exclusively as mapped minidisks should be made ineligible for minidisk cache.

The processing associated with page fault resolution serializes a virtual machine. The Asynchronous Page Fault capability is available to address the impact of server virtual machine page fault serialization on other dependent virtual machines. Asynch Page Fault allows a virtual machine to continue processing on other work (a different task), while CP handles the page fault. The implementation applies only to page faults of data space pages. CP will provide an interrupt when the page fault is complete. At that time the server application can finish the processing the original task associated with the page fault.

The server application requires logic to work in this environment. This includes:
  • A structure that lends itself to tasking or work units.
  • Selection of asynchronous page fault function on a data space by space basis. This occurs when adding the data space to the access list.
  • Using CP macro PFAULT to establish token for hand shaking.
  • Support to handle the associated interrupts.

The PAGEX support is based off the same idea. There are two significant differences between the two:

  1. PAGEX deals with the primary address space while the Asynchronous Page Fault support is limited to VM Data Spaces.
  2. Asynchronous Page Fault was designed with server virtual machines in mind. The hand shaking interface with CP is easy to work with and lends itself nicely to server applications.

Disk mapping can further improve performance through the use of another CP macro, REFPAGE. This macro allows an application to specify its upcoming storage reference patterns. The z/VM paging subsystem uses this information to form blocks of pages that are related to the application's future reference pattern. When the paging subsystem needs to reference a DASD for one page of a block, it loads the entire block into the data space, eliminating the need to access the DASD on subsequent references to other pages.