International Business Machines Corporation

Richard Roland Guyette

Paul Gregory Greenstein

John Ted Rodell

Robert Edward Galbraith

Kenneth J Oakes

Leslie W Wyman

Roger E Hough

Marten J Halma

William H Tetzlaff

Robert Baird

Paul Hodges

Kenneth J Fredericks

Gerald P Bozman

James J Myers

Alexander S Lett

Suzanne M John

James C Mazurowski

Thomas Beretvas

Apparatus for protecting memory storage blocks (page frames) against unwanted I/O accesses, including I/O data transferred in an unwanted direction. I/O storage keys are provided in an I/O protection array. Each I/O key is comprised of one or two bits and is associated with a respective storage block in computer memory. If the array contains two bit I/O keys, each key has 4 settings for controlling I/O accesses to an associated storage block; which: 1) inhibit an I/O access in the input direction of I/O data flow, 2) inhibit an I/O access in the output direction of I/O data flow, 3) allow I/O accesses in both directions, or 4) prevent all I/O accesses. If the array contains single bit I/O storage keys, each key has two settings, which: 1) prevent all I/O accesses in the associated storage block, or 2) allow all I/O accesses in the associated block. No I/O program keys are needed for controlling this type of I/O protection, which avoids key comparison operations by the I/O access protection apparatus. Nevertheless, the use of the subject I/O protection apparatus does not prevent the use of apparatus for protecting the same storage blocks from unwanted accesses by central processors, which may use CPU storage keys. Such CPU storage keys may be contained in a hardware array, or may be contained in a virtual storage page table without having any hardware CPU storage key array. If desired, the subject I/O storage protection apparatus may be used without providing any CPU storage protection.

Apparatus for protecting memory storage blocks from I/O accesses

I/O protection key processes for protecting storage blocks (page frames) in a shared main storage against unwanted I/O accesses. Independent CP (central processor) key protection may optionally be provided to protect the same storage against unwanted CP accesses. Processes are included for initializing, and addressing I/O buffers used by the I/O programs; each I/O buffer is comprised of a contiguous set of the blocks (page frames). The I/O keys may be used independently of any CP keys provided for protecting the same blocks against unwanted accesses by any CP in the system. The I/O keys must be supported by a hardware I/O storage array when only real (or absolute) addressing is used by I/O programs. However, the CP keys may be supported by either real CP keys in a second hardware key array; or alternatively the CP keys may be provided as virtual CP keys in a field in each page table entry (which is used for translating CP virtual addresses to CP real addresses). The separate I/O and CPU access protection functions may each include any or all of: write protection, read protection, and storage key protection for page frames.

Method for managing I/O buffers in shared storage by structuring buffer

Protection against unwanted I/O accesses in main storage blocks/page frames independent of any storage protection provided against unwanted CPU accesses. An I/O protection array is used containing one-bit I/O keys used only for protecting which respectively protect associated blocks/page frames from unwanted accesses by I/O programs. Each one-bit I/O key is used to allow or disallow I/O accesses into an associated storage block. Any CPU access is not affected by the I/O storage key. No I/O program key is used and therefore no key compare operation is required. However, the embodiment is compatible with use of CPU storage protection using CPU storage keys in either real form in a CPU storage key array, or in virtual form in page table entries without using any CPU storage key array.

System for storage protection from unintended I/O access using I/O

Main storage access protection against unwanted I/O accesses in storage blocks/page frames independent of any protection provided against unwanted CPU accesses. I/O programs are each assigned an I/O program key which is matched against an I/O storage key selected from an I/O storage protection array used only for protecting blocks from accesses by I/O programs, but not from any accesses by CPU programs. The address of each storage access request by an I/O program selects a key entry in the array containing the I/O storage key used in the comparison with the I/O program key. Each entry in the I/O storage array may also contain a second I/O storage key which may be either a one-bit type as described and claimed in application Ser. No. 08/652,197 or a two-bit type as described and claimed in application Ser. No. 08/652,079, both applications of which were filed on the same day as this application and assigned to the same assignee. CPU storage protection array is not required for I/O storage protection, but CPU storage protection may be added for protecting storage blocks against unwanted accesses by CPU programs. Either real or virtual CPU storage key protection may be added as compatible with the subject I/O storage protection arrangement. The separate I/O and CPU access protection functions may each include any or all of: write protection, read protection, and storage key protection for page frames.

Apparatus for protecting storage blocks from being accessed by unwanted

In a data processing system, a hardware system area ('HSA') storage is associated with the hardware configuration of the system. A change in the system hardware configuration typically corresponds to a change in HSA size. Upon determination of the requirement for, for example, increasing the size of HSA, a region of storage is freed from use as central storage or expanded storage. The freed region is incorporated into the data processing system as HSA storage. The process may be reversed to reduce the size of HSA by converting a region of HSA into either central storage or expanded storage.

Method and system for dynamically changing the size of a hardware system

A dynamic reconfiguration request for a change in a system's physical configuration is transmitted from a configuration controller to a hypervisor controlling operating systems executing in one or more partitions of the system. The hypervisor translates the physical reconfiguration request into a request for reconfiguration of logical resources known to the operating systems, first verifying it against an installation policy, and passes the requests to the operating systems in the partitions. The operating systems perform logical reconfiguration, then request physical reconfiguration of the hypervisor. The hypervisor initiates the physical reconfiguration through the configuration controller.

System and method for dynamically performing resource reconfiguration in

A program stored on a portable storage medium for transferring the program from/to a data processing system, including to or from a disk medium in the system. The program manages I/O buffers that use I/O storage protection key for protecting storage blocks (page frames) in a shared main storage against unwanted I/O accesses, but the I/O storage keys do not protect the storage blocks from an CP (central processor) accesses. CP key protection may optionally be provided to independently protect the same storage block against unwanted CP accesses. Processes initialize, and address I/O buffers used by I/O programs; each I/O buffer is comprised of a contiguous set of the blocks (page frames). The I/O keys are used independently of any CP keys, and both I/O and CP keys are required for protecting any block against unwanted accesses by both I/O and CP accesses. The I/O keys are supported by a hardware I/O storage key array when real (or absolute) addressing is used by I/O the programs. However, the CP keys may be, but need not be, supported by CP keys in a second hardware key array; since the CP storage keys instead may be supported as virtual CP keys in CP key fields in page table entries (which are used in translating CP virtual addresses to CP real addresses). The separate I/O and CPU storage protection functions may each include any or all of: write protection, read protection, and storage key protection for page frames.

A method for dynamically detecting loss of map integrity in a form of system-managed storage (SMS). In SMS, maps are used to define access paths to data and to allocate and reallocate storage resources among applications running thereon. The method steps include incorporating as an indivisible part of an overwriting commmand the duplication of map information by appending a portion of it to each data block in store, and detecting loss of map integrity as a function of a comparison mismatch between the portion stored with a counterpart data block and the map upon each read/write access.

Method for verification and restoration of directories in CPU system

Enables any OS of plural OSs within any of plural logical-resource partitions (LPARs) of a CEC to use interpretive execution for synchronously-executable CHSC (channel subsystem call) commands. A CHSC command authorization mask (CCAM) is provided to control which CHSC commands are allowed to execute interpretively (with pass-through), and which commands are executed with hypervisor intervention (as all prior CHSC commands did). By enabling interpretive execution of those commands which can successfully operate with pass-through, significant system efficiency is obtained. And by disabling interpretive execution for a subset of CHSC commands (which are not allowed to execute with pass-through) potential system failures may be prevented. Thus, interpretive execution may be restricted differently among the OSs in a CEC. Novel CHSC command execution now handles multiple images of shared I/O resources by use of image identifiers, which could not be done before. The information requested by any OS issuing a CHSC command is filtered and optionally compacted by the I/O subsystem responding to the command by only providing information obtained from control blocks associated with the OS which issued the command. This is done by having a set of control blocks for each I/O resource, each control block in the set being associated with a particular OS.

Growing community of inventors

LaGrangeville, NY, United States of America

Richard Roland Guyette