HK1201347B - Providing by one program to another program access to a warning track facility - Google Patents

Description

Providing access to warning tracking facilities from one program to another

Technical Field

Aspects of the present invention generally relate to processing within a computing environment, and more particularly, to facilitating processing associated with shared resources.

Background Art

One type of resource-sharing environment is a virtual environment, which includes a host central processing unit (CPU) and one or more client central processing units. A host program (e.g., a host operating system) executing on the host CPU provisions the client CPUs (also known as virtual CPUs). The host program performs actions to allocate resources from the underlying host configuration and assign those resources to the client CPUs.

In one specific embodiment, a guest CPU exists when the host CPU enters interpreted execution mode. At this point, the guest operating system (also referred to herein as the guest program) begins execution on the virtualized CPU, while the host program temporarily suspends execution on the host CPU. At the end of interpreted execution mode, the host program resumes execution on the CPU. Linking technology exists between the host and guest, allowing host and guest states to be saved and restored. Typically, when the host program launches a guest program, the host program is temporarily suspended until the guest program returns. The guest CPU and host CPU are both different modes of the host CPU.

A host configuration typically includes all of a computer system's resources. These resources include, but are not limited to, the central processing unit (CPU), main memory, and input/output (I/O) devices. In this system, multiple client CPUs can be supported by a single host CPU. This is achieved by assigning each client CPU a period of time, called a timeslice, to use the host CPU, then moving the host CPU to another client CPU for a timeslice, and so on. The number of client CPUs a host CPU can support varies depending on the host CPU's capabilities and the desired capabilities to be assigned to each client CPU.

A guest configuration is typically formed from two or more guest CPUs and is referred to as a guest multiprocessing (MP) configuration. Each guest CPU can be configured by sharing a separate host CPU or even by sharing a single host CPU. One property of this sharing is that a guest CPU can be operational for a period of time called a time slice and then inactive for some arbitrary period of time. The inactive period varies based on the priority policy established by the system, the total number of guest CPUs that will share the host CPU, and the specific sharing technology being used.

In this client multiprocessing system, a program, sometimes referred to as a dispatchable unit (DU), may be dispatched by the guest operating system on a client CPU, and then during the execution of the dispatchable unit, the host time slice for the dispatchable unit expires. This situation may place the dispatchable unit in a condition such that the dispatchable unit cannot be continued on any other client CPU in the client multiprocessing configuration, regardless of the availability of any other client CPUs. Specifically, the dispatchable unit must wait for a unique client CPU to receive its next time slice in order to continue. Based on the sharing technology and the relative priorities of the client configurations, the next time slice may be delayed for a considerable period of time. Even if the client configuration has other client CPUs capable of executing the dispatchable unit, continuation of the dispatchable unit is not possible (due to the state of the dispatchable unit's client CPU that was saved at the expiration of the previous time slice). The dispatchable unit is inactive until the precise state is available for the client CPU to continue.

Summary of the Invention

The shortcomings of the prior art are overcome and advantages are provided by providing a computer program product for facilitating processing in a computing environment. The computer program product includes a computer-readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method includes, for example: providing, by a first program, an indication that a warning tracking facility has been installed in the computing environment to a second program, the warning tracking facility providing a grace period to the second program to perform a first function; notifying, by the first program, the second program that the grace period has begun; and performing, by the first program, a second function after the grace period.

Methods and systems related to one or more aspects of the present invention are also described and claimed herein. Additionally, services related to one or more aspects of the present invention are also described and may be claimed herein.

Additional features and advantages are realized through the techniques of the present invention.Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more aspects of the present invention are particularly pointed out and clearly claimed as examples in the claims at the end of the specification. The foregoing content and objects, features and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

FIG1 depicts an embodiment of a computing environment that incorporates and uses one or more aspects of the present invention;

FIG2 depicts another embodiment of a computing environment that incorporates and uses one or more aspects of the present invention;

FIG3 depicts yet another embodiment of a computing environment that incorporates and uses one or more aspects of the present invention;

FIG4 depicts an embodiment of logic associated with alerting a client observation of an outage tracking facility according to aspects of the present invention;

FIG5 depicts an embodiment of logic associated with alerting a host observation of a tracking outage facility according to aspects of the present invention;

FIG6 depicts an embodiment of logic associated with a host handling a client exit according to aspects of the present invention;

FIG7 depicts an embodiment of an overview of warning tracking interruption facility logic according to aspects of the present invention;

8A-8C depict embodiments of logic associated with warning trace interruption facility processing according to aspects of the present invention;

FIG9 depicts an embodiment of logic associated with receiving a warning tracking interrupt according to aspects of the present invention;

FIG10 depicts an embodiment of the format of a diagnostic instruction used in accordance with aspects of the present invention;

FIG11 depicts an embodiment of a computer program product incorporating one or more aspects of the present invention;

FIG12 depicts an embodiment of a host computer system containing and using one or more aspects of the present invention;

FIG13 depicts another example of a computer system that can contain and use one or more aspects of the present invention;

FIG14 depicts another example of a computer system including a computer network that incorporates and uses one or more aspects of the present invention;

FIG15 depicts an embodiment of various components of a computer system that may contain and use one or more aspects of the present invention;

FIG16A depicts an embodiment of an execution unit of the computer system of FIG15 incorporating and using one or more aspects of the present invention;

FIG16B depicts an embodiment of a branching unit of the computer system of FIG15 that incorporates and uses one or more aspects of the present invention;

FIG. 16C depicts an embodiment of a load/store unit of the computer system of FIG. 15 incorporating and using one or more aspects of the present invention; and

FIG. 17 depicts an embodiment of a simulated host computer system that incorporates and utilizes one or more aspects of the present invention.

DETAILED DESCRIPTION

According to aspects of the present invention, a capability is provided for warning a program (e.g., an operating system) that it has a grace period to perform a function. For example, the program is given a grace period to perform cleanup (e.g., complete, stop, and/or move dispatchable units).

According to another aspect of the present invention, a program and/or processor is warned that it will lose access to a resource (e.g., a shared resource). For example, a processor that shares a resource with other processors is warned that the processor will lose access to the resource. As another example, a program such as an operating system executing on a shared processor (i.e., a program that shares the processor with other programs) is warned that it will lose its processor resources.

In one particular embodiment, the following capability is provided: providing a guest program executing on a guest CPU provisioned by a host CPU with a warning of the expiration of a timeslice granted to the guest CPU by the host CPU, or a warning of the host prioritizing execution of a timeslice over a guest CPU, wherein the warning provides a grace period that the guest CPU can use to perform certain functions, such as completing execution of a dispatchable unit, stopping the dispatchable unit at a point where it is re-dispatched, and/or moving the dispatchable unit to another guest CPU.

As used herein, a grace period includes, by way of example, an amount of time, a number of instructions, a number of cycles, etc. The grace period has a predetermined duration during which one or more functions may be executed.

One embodiment of a computing environment that includes and uses one or more aspects of the present invention is described with reference to FIG1 . In this particular embodiment, the computing environment 100 includes a plurality of processors 102 that share resources 104. Each processor (and/or a program executing on the processor, such as an operating system) is given a certain amount of time, called a time slice, to share the resources. As examples, resources include central processing unit resources, memory, input/output devices or interfaces, and/or other resources. A processor (or program executing on the processor) that has access to a resource is warned that the processor's access is about to end, and therefore, the processor (or program) is to perform a specific action, such as cleanup, completing a work unit, stopping a work unit, moving a work unit, etc.

Another embodiment of a computing environment 200 that incorporates and uses one or more aspects of the present invention is described with reference to FIG2 . The computing environment 200 is based on, for example, the z/ Architecture Principles of Operation publication No. SA22-7832-08, Revision 9, dated August 2010, provided by International Business Machines Corporation (Armonk, New York), which is hereby incorporated by reference in its entirety. In one example, the computing environment includes servers provided by International Business Machines Corporation (Armonk, New York). [The following sentences appear to be unrelated and should likely be omitted.] [The following sentences appear to be unrelated and should likely be omitted.] [The following sentences appear to be unrelated and should likely be omitted.] [The following sentences appear to be unrelated and should likely be omitted.] [The following sentences appear to be unrelated and should likely be omitted.]

As an example, computing environment 200 includes a central processor complex (CPC) 202 that provides virtual machine support. CPC 202 includes, for example, one or more virtual machines 204 (or, in another embodiment, logical partitions), one or more central processors 206, at least one host 208 (e.g., a control program such as a hypervisor), and an input/output subsystem 210, each of which is described below. In this example, the virtual machines and the host are contained in memory.

As an example, CPC's virtual machine support provides the ability to operate a large number of virtual machines, each capable of hosting a guest operating system 212 such as Windows XP or Linux. Each virtual machine 204 can function as a separate system. That is, each virtual machine can be independently reconfigured, host a guest operating system, and operate with different programs. The operating system or application running in the virtual machine appears to have access to a complete and intact system, but in reality, only a portion of the system is available.

The CPC's physical resources (e.g., CPU, memory, I/O devices, etc.) are owned by the host 208, and the shared physical resources are allocated by the host to the guest operating systems as needed to meet the guest operating systems' processing needs. The interaction between the guest operating systems and the physical shared machine resources is controlled by the host, as the large number of guests often prevents the host from simply partitioning and assigning hardware resources to the configured guests.

The central processor 206 is a physical processor resource that can be assigned to a virtual machine. For example, a virtual machine 204 includes one or more logical processors, each of which represents all or a share of the physical processor resource 206 that can be dynamically allocated to the virtual machine. Virtual machines 204 are managed by a host 208. As examples, the host can be implemented as microcode executing on processor 206, or can be part of a host operating system executing on the machine. In one example, the host 208 is a processor resource/system manager (PR/SM) supplied by International Business Machines Corporation (Armonk, New York).

The input/output subsystem 210 directs the flow of information between devices and main storage. The input/output subsystem 210 is coupled to the central processing complex, in which regard, the input/output subsystem 210 can be part of the central processing complex or separate from the central processing complex. The I/O subsystem relieves the central processor of the task of directly communicating with I/O devices coupled to the CPC and allows data processing to proceed simultaneously with I/O processing.

In one embodiment, the host (e.g., PR/SM) and processor (e.g., ) hardware/firmware interact with each other in a controlled, cooperative manner to process guest operating system operations without requiring the transfer of control to/from the guest operating system and the host. Guest operations can be executed directly without host intervention via a facility that allows instructions to be interpreted for the guest. This facility provides a host-issued instruction, "Start Interpretive Execution (SIE)," which specifies a control block, called a state description, that holds guest (virtual machine) state and control. This instruction places the CPU in an interpretive execution mode, directly processing guest instructions and interrupts, until a condition requiring host attention occurs. When this condition occurs, interpretive execution ends and a host interrupt is presented, or the SIE instruction completes and stores details of the condition encountered; an action hereafter referred to as an intercept. An example of interpretive execution is described in "System/370 Extended Architecture/Interpretive Execution," September 1985 (IBM Publication No. SA22-7095-01), which is hereby incorporated by reference in its entirety.

As used herein, firmware includes, for example, microcode, millicode, and/or macrocode for a processor. Firmware includes, for example, hardware-level instructions and/or data structures for implementation in higher-level machine code. In one embodiment, firmware includes, for example, proprietary code, typically delivered as microcode that includes trusted software or underlying hardware-specific microcode and controls operating system access to system hardware.

Another example of a computing environment incorporating one or more aspects of the present invention is depicted in FIG3 . In this example, an emulated host computer system 300 is provided that emulates a host computer 302 of a host architecture. In the emulated host computer system 300, a host processor (CPU) 304 is an emulated host processor (or virtual host processor) and is implemented via an emulated processor 306 having a native instruction set architecture different from the native instruction set architecture used by the processor of the host computer 302. The emulated host computer system 300 has memory 308 accessible to the emulated processor 306. In an example embodiment, the memory 308 is partitioned into a host computer memory portion 310 and an emulated routine portion 312. The host computer memory 310 is available to programs of the emulated host computer 302 according to the host computer architecture and may include both a host or hypervisor 314 and one or more virtual machines 316 executing guest operating systems 318 (similar to the similarly named components in FIG2 ).

The emulation processor 306 executes native instructions of an architecture constructed from an instruction set different from the architecture of the emulation processor 304. For example, the native instructions are obtained from the emulation routine memory 312. The emulation processor 306 can access host instructions for execution from a program in the host computer memory 310 using one or more instructions obtained in a sequence and access/decode routine. The sequence and access/decode routine can decode the accessed host instructions to determine a native instruction execution routine for emulating the function of the accessed host instructions. A host instruction can be, for example, a start interpret execute (SIE) instruction, by which the host attempts to execute a guest program in the virtual machine. The emulation routine 312 may include support for this instruction and is used to execute a sequence of guest instructions in the virtual machine 316 according to the definition of this SIE instruction.

As an example, other facilities defined for the architecture of host computer system 302 can be emulated by constructed facility routines, including facilities such as general registers, control registers, dynamic address translation, I/O subsystem support, and processor caches. The emulation routines can also utilize functions available in the emulated processor 306 (such as general registers and dynamic translation of virtual addresses) to improve the performance of the emulation routines. Specialized hardware and offload engines can also be provided to assist the processor 306 in emulating the functions of the host computer 302.

According to aspects of the present invention, a warning tracking interrupt facility is provided that can be used in many types of computing environments. While the warning tracking interrupt facility can be used in many types of environments, aspects of the facility are described herein with reference to a client multiprocessing system. As described above, in a client multiprocessing system, a client operating system dispatches dispatchable units (e.g., programs, program code, etc.) onto client central processing units (CPUs), which are hosted by at least one host CPU. The host CPU provides a time slice (e.g., a time quantum or other time period, such as a number of instructions, a number of cycles, etc.) to the client CPUs during which the dispatchable unit executes. If the time slice expires during the execution of a dispatchable unit, the dispatchable unit may be placed in a state where it cannot continue on any other client CPU in the client multiprocessing configuration, regardless of the availability of any other client CPUs. Specifically, the dispatchable unit must wait for a unique client CPU to receive its next time slice in order to continue. Depending on the specific sharing technology used and the relative priorities of the client configurations, this delay may be considerable. Even if the guest configuration has other guest CPUs capable of executing the dispatchable unit, continuation of the dispatchable unit is not possible (due to the state of the guest CPU of the dispatchable unit being saved at the expiration of the previous timeslice). The dispatchable unit is inactive until the accurate state is available to continue the guest CPU.

It is possible to extend the time slice by granting additional time (or other additional time periods, such as additional instructions, cycles, etc.), but even with this additional time, the client CPU can extend the execution of the dispatchable unit while still leaving the dispatchable unit in the same undispatched state, since it will be at the expiration time of the normal time slice.

Because the host program is unaware of the controls and state used by any guest program executing any dispatchable unit, it is not possible to consistently grant the guest operating system extra time to clean up its dispatchable units without establishing a protocol between the host and guest programs. Without this protocol, any extra time granted to the guest CPU will be consumed by the main process, and the client may still end up with the same dispatchable unit jam. Therefore, according to aspects of the present invention, such a protocol is provided.

According to aspects of the present invention, a grace period or extended time is provided that includes a warning indicating to the guest program that a specific action should be taken (e.g., completing a dispatchable unit or making a dispatchable unit re-dispatched). As an example, a grace period is provided in response to the expiration of a timeslice or in response to the host prioritizing execution of the guest before the expiration of a timeslice in order to reclaim the processor for some other higher priority as seen by the host, as described in further detail herein.

As an example, a grace period is provided rather than unconditionally extending the time slice. If the normal time slice has fully expired, a grace period is provided, but the next normal time slice is offset to maintain fairness for all other virtualized guests with their own time slice expectations. If the normal time slice has not yet expired, the grace period is taken from the remaining normal time. In short, the grace period limits the remaining time (or other period) given to the guest CPU and is itself non-extendable. Therefore, the guest CPU cannot continue execution for an arbitrary and unknown period of time.

At the beginning of the grace period, the guest program is notified for the purpose of cleaning up the dispatchable unit (e.g., completing the dispatchable unit, stopping the dispatchable unit, and/or moving the dispatchable unit). Enforcement of the grace period ensures that the guest CPU does not exceed the additional time period granted. The protocol by which the guest program is granted a grace period and notifies the guest program that the time (or other time period) is almost expired (the grace period has begun) is an agreement between the guest program and the host program, which the guest program understands and thus makes this notification worthwhile. That is, the guest program will generally honor the notification by making the current dispatchable unit dispatchable on another guest CPU in the guest configuration (e.g., moving the dispatchable unit) if necessary.

Further details regarding the protocol and the warning tracking interruption facility (also referred to as warning tracking or warning tracking facility) are described below with reference to Figures 4 through 10. The embodiments described with reference to those figures relate to a virtualized environment having one or more clients deployed by one or more hosts. However, one or more aspects of the present invention also relate to other environments, including non-virtualized environments where multiple processors and/or multiple processes share resources.

4, details regarding the protocol for tracking the interruption of a facility as observed by a client are described. The protocol for tracking the interruption of a facility as observed by a client includes, for example, facility installed indication, client registration, notification, and voluntarily exiting, each of which is described below.

4 , the client program understands the warning trace protocol and searches for an indication that the facility is installed (step 400). In one example, this indication is a bit stored in a control block (e.g., a "Service Call Control Block (SCCB)") that is observed using a read command such as a "read SCP information" command. After determining that the facility is installed, the client program performs registration (step 402). Registration is a mechanism by which the client program communicates to the host program that the client program understands the warning trace interrupt facility protocol. In one example, registration is performed using diagnostic instructions, examples of which are further described below.

In one embodiment, registration initiated from any client central processing unit covers all client central processing units of a multi-processing configuration, because consistent behavior is desired across client CPUs of a client multi-processing configuration. In a client multi-processing configuration, the client CPUs use the same main memory, and it is assumed that the client CPUs operate in an image, sometimes referred to as a single image. Therefore, registration for one client CPU applies to other client CPUs of a multi-processing environment. In one embodiment, registration is irrevocable, and this helps avoid timing windows, simplifies development, and allows for improved testability. Even if registration is irrevocable, the client program can determine whether the client program will continue to participate in the protocol. If the client program so chooses, the client program need not participate by resetting or having reset one or more enable indicators described below.

After registering the guest program for the alert tracking protocol, the guest CPU may be notified of a grace period (step 404). For example, the host CPU may warn the guest CPU of the expiration (or, in another example, the impending expiration) of its time slice or the prioritization of its time slice. In one specific example, the CPU of a registered guest configuration is notified of, for example, the expiration of its normal time slice and the beginning of a grace period that provides an additional period for, for example, cleanup.

After being notified, the client has a constrained amount of time or other period, a grace period (e.g., 50 microseconds in one specific embodiment) to make the dispatchable unit re-dispatched or make any other appropriate adjustments. If the normal time slice has ended, then the grace period is used, for example, before returning control to the host, to make the dispatchable unit re-dispatched or make any other appropriate adjustments. If the time slice has not ended, then the grace period is used and any remaining portion of the time slice is discarded. Normal accounting of actual time used by the client CPU occurs.

After the notification is made, the guest CPU is in a constrained period (e.g., a finite amount of time) after which the guest CPU's operation is involuntarily terminated. Only one notification is made for each normal time slice period. Thus, the guest CPU remains subject to the ultimate timing control constraints that ensure the underlying shared host CPU can be shared elsewhere, thereby preserving good order and regularity in the overall virtualization provided by the host program.

Notification can be achieved by any mechanism that allows the guest program to detect a unique state. Examples include a unique guest interrupt, an architecturally defined main memory location that can be configured, or an I/O external memory device available to both the host and the guest. The first of these three requires appropriate guest enablement to allow interrupts. The latter two require sufficiently frequent periodic checks that do not waste grace periods. In one specific example, a guest interrupt called a warning trace interrupt (WTI) is used for notification.

After being warned, the client actively exits its given time slice/grace period (step 406). After being notified and making the dispatchable unit re-dispatched (e.g., stopping the dispatchable unit and moving the dispatchable unit, or completing the dispatchable unit), the client ends the current time slice/grace period. This exit signals the host program that the client is actually following the protocol. Other reasons may occur for the client to relinquish control and therefore return to the host program. Typically, for constrained processing that makes the dispatchable unit re-dispatched, no conditions will occur for any of these external exits. If the client CPU exits within the grace period via the warning tracking interrupt protocol, a feedback indication regarding the next time slice is given whenever this condition occurs. Thus, the client program knows that it has met the time constraints imposed by the grace period.

If a guest delays its voluntary exit, the expiration of the grace period allows its execution to be prioritized. The next time the guest CPU is activated with a normal time slice, a feedback indication is provided, letting the guest know it was delayed. This can be used to troubleshoot guest programs, as the usual grace period allows ample time for cleanup and voluntary exit.

If an external exit occurs, the next time the guest CPU is started within a normal time slice, it is expected that an active exit will occur quickly. The same feedback mechanism will inform the guest program that an external exit has been intervened and thus provide different information to inform problem determination.

Active exit is achieved by any mechanism that allows control to be transferred from the guest program through the host program, including the feedback mechanism described above. The mechanism used will be defined in the warning trace interrupt protocol of the specific architecture so that the host program can recognize the guest request. In one example, this mechanism includes the diagnostic instructions described below.

In addition to client observation of the alert tracking outage protocol, in one embodiment, the host also observes the facility, as described in further detail below with reference to FIG. 5 .

5 , the host identifies the facility installed indication and reflects it to its client (step 500). For example, the host checks the installed bit in the control block (e.g., SCCB) and identifies the installed state of the warning tracking protocol (i.e., it is set) and knows how the host program can use this state to the host's advantage. Therefore, the facility indication is reflected to its client. For example, to reflect the facility to the client, the host sets the installed bit in the client control block (e.g., the client SCCB) or a memory area accessible to the client. If, for any reason, the host program does not want the client to observe the installed state of the warning tracking interrupt facility protocol and does not allow the client to observe and use the installed state of the warning tracking interrupt facility protocol, the host program passes a not installed indication to the client (e.g., sets the client-visible bit to zero). In addition, in one embodiment, the host program sets the control of the client CPU so that the warning tracking protocol is disabled (e.g., turns off one or more designated bits in the status description of the client CPU).

As the client initiates registration, the host program receives the unsolicited registration request and remembers that the client is already registered (step 502). A registration request initiated by any single client CPU is sufficient to register all client CPUs in the client multi-processing configuration. Therefore, the host program enables the warning trace protocol for all CPUs in the client configuration (step 504). For example, the host program sets one or more designated bits in the state description of the client CPU to enable the warning trace interrupt facility for the client. No feedback on the registration needs to be sent back to the client. If the client CPU attempts to register even when the facility is not installed, the host will ignore the request and will not enable the client CPU for the warning trace interrupt facility protocol.

After registering and enabling the client for the alert tracking facility, the client may receive notifications about invocations of the protocol (step 506). This may be achieved in several scenarios, as described below.

As an example, when the Warning Trace Interrupt protocol is enabled for a guest CPU operating in interpreted execution mode on a host CPU (i.e., host CPU X), the host program may initiate the protocol from host CPU Y. That is, the guest CPU has already been provisioned by host CPU X and is currently unavailable to the host program. If the host program must reacquire CPU X, the host program first causes CPU X to exit interpreted execution mode. That is, it halts the guest CPU, thereby exiting CPU X's interpreted execution mode. Halting the guest CPU at any arbitrary point without allowing the guest CPU to proactively halt itself risks creating the very problem the Warning Trace Interrupt protocol is intended to address. The Warning Trace Interrupt protocol allows host CPU Y to request notifications by allowing host program actions to be converted into notifications in guest CPU X (step 506). Since the guest program has previously registered, the host program expects that the guest program will recognize the notifications and support appropriate handling of the notifications, including the final step of proactively terminating execution, thereby returning control of host CPU X to the host program. Once this occurs, the host program can continue regardless of any program activations that may have occurred due to the use of host CPU X.

The host program notifies the client by, for example, setting any state, setting an indicator (e.g., a bit), or causing an unsolicited asynchronous signal (e.g., a warning trace interrupt) to be sent to the client. Despite registration, the time of receipt of this notification signal remains unknown in the client. By registering, the client has just agreed to abide by the protocol if notified by the signal.

In a single-processor host system, if one host CPU is in interpretive execution mode, thus enabling the guest CPU to operate, there is no other host CPU to invoke the warning trace interrupt protocol. However, even in this case, when the host CPU recognizes the expiration of a time slice while in interpretive execution mode, the CPU itself can still invoke the warning trace interrupt protocol, and can then grant a grace period and perform the notification.

In another example of notification, notification occurs when the host CPU causes a notification defined in the warning trace interrupt protocol to be sent to the guest CPU (due to an internal state change recognized by the host CPU while the host CPU is in interpreted execution mode). This occurs when the guest CPU is enabled for the warning trace interrupt protocol and the host CPU recognizes the end of a time slice. Before signaling the guest CPU to relinquish control, the CPU internally grants a grace period to allow the guest CPU sufficient time to receive the signal, take appropriate action (e.g., complete the currently dispatchable unit or make the currently dispatchable unit re-dispatched), and proactively terminate. Internally, the host CPU maintains state indicating that the guest CPU has been notified. If the guest does not proactively terminate within the grace period, the CPU recognizes this and terminates the guest's execution, thereby returning control to the host program by terminating interpreted execution mode. In one embodiment, the guest cannot determine why the protocol was invoked, but only determines that it was notified to clean up and terminate. Other host rationales for causing the termination of interpreted execution mode and, therefore, terminating guest execution may exist. For example, there are scenarios where all guest CPUs are stopped to make a coordinated change to the entire guest configuration. A multi-processing guest configuration does not have some CPUs operating under different rules or assumptions than the other CPUs in the guest configuration. This asymmetry can produce unpredictable guest results.

The host CPU receives the effects of the guest CPU having performed an active exit or an exit for any other reason (e.g., returning CPU resources to the host) (step 508). If the exit was due to a reason defined by the warning trace interrupt protocol, the host program remembers to provide feedback to the guest CPU the next time the guest CPU is started (regardless of how long that may be). This feedback is a positive ("good") indication, assuming the guest exited voluntarily before the grace period expired. If the exit was due to any other reason, no warning trace interrupt protocol feedback occurs the next time the guest CPU is started.

If a guest delays an active exit—that is, the guest performs actions to actively exit, but the grace period has expired—then the expiration of the grace period prioritizes the guest CPU's execution. The next time the guest CPU is activated with a normal time slot, an exception feedback indication is provided, letting the guest know that it has delayed its active exit. This situation can generally be used to troubleshoot problems in guest programs, as the normal grace period allows ample time for cleanup and active exit.

If an exit other than an active exit of the warning trace interrupt protocol occurs, the next time the guest CPU is started with a normal time slice, feedback according to the warning trace protocol will not be included.

The means of actively exiting is to realize by making control be passed to any mechanism of host program from client program, and this mechanism is identified as protocol active exit by host program, and this mechanism includes above-mentioned feedback mechanism.In one example, diagnostic instruction is used for active exit.That is, diagnostic instruction with specific parameters is used to indicate the completion of time slice.After diagnostic instruction is issued by client program and is executed, host program determines whether exit is on time.Then, when restarting client (it is the next sequential instruction after diagnosis), provide indication restart client whether condition code.Condition code, for example, is set in the client program status word (PSW) that is used to start client at next sequential instruction place.Client can then test condition code.

Referring to FIG6 , the host's handling of a proactive guest exit is further described. Initially, when the guest CPU is stopped, control returns to the host CPU (step 600). A determination is made as to whether control returns within a grace period (query 602). If control returns within the grace period, the host program observes the proactive guest exit according to the warning trace interrupt protocol and remembers good feedback for the next boot of the guest CPU, regardless of which host CPU may have deployed the guest CPU at that time (step 604). This assumes that the warning trace interrupt facility is installed. If control does not return within the grace period, the feedback status is not remembered. However, if the guest performs an action to proactively exit, but the proactive exit is outside the grace period (query 602), the host program on the host CPU observes the proactive guest exit according to the warning trace interrupt protocol (even if the guest ultimately and inevitably exits involuntarily) and remembers bad feedback for the next boot of the guest CPU, regardless of which host CPU may have deployed the guest CPU at that time (step 606). Again, this assumes that the warning trace facility is installed. Otherwise, the feedback status is not remembered.

Thereafter, regardless of whether the host remembers good feedback or bad feedback, the host program redirects the host CPU to the priority execution assignment (step 608). That is, the host is redirected to now execute one or more functions that return its resources (CPU).

Furthermore, when the next sequential instruction of the guest CPU is started, regardless of which host CPU configures the guest CPU, if the feedback state is remembered, the feedback state indicator is set before starting the guest CPU (step 610). In one example, the feedback state indicator is set in a SIE state description (e.g., in a PSW of the state description), and the SIE state description indicates the start of the next sequential instruction.

Additional details regarding the processing associated with the warning trace interrupt facility are described with reference to Figures 7 through 9. Specifically, Figure 7 depicts one embodiment of the logic associated with an overview of the warning trace interrupt facility processing; Figures 8A through 8C provide details of the warning trace interrupt facility processing according to aspects of the present invention; and Figure 9 depicts one embodiment of the logic associated with receiving a warning trace interrupt.

Referring to FIG. 7 , initially, a client program (e.g., a guest operating system) recognizes that a warning trace interrupt facility has been installed (step 700 ). In one embodiment, this is accomplished by the client program observing an installed facility indicator, such as a bit, located, for example, in a designated control block. If the guest operating system has support for participating in the warning trace interrupt facility, the guest operating system recognizes the warning trace interrupt facility installed indicator and then indicates its ability to participate in the protocol. In one example, this includes registering the client's intent to participate in warning trace processing (step 702 ). As described herein, in one example, registration is performed via diagnostic instructions. Upon registration, the guest operating system indicates to both the host CPU and the host program that the guest operating system understands how to handle a warning trace interrupt (WTI), which is an explicit interrupt that provides a warning to the guest that, for example, the guest will lose access to its shared resources, such as the guest CPU, and that, for example, the guest should take action regarding its currently executing dispatchable unit. In one embodiment, registration is a prerequisite for receiving a WTI. If the guest is not registered for the warning trace interrupt facility, no grace period is provided after the guest's time slice expires and the guest CPU is taken out of interpretive execution mode.

In one embodiment, even if registered, a guest program has two mechanisms for disabling the presentation of a WTI. For example, a selected bit in the program status word (PSW) can be set to zero, which disables the presentation of all external interrupts, including the WTI; or a bit in a designated control register (e.g., CR0) can be set to zero to disable only the WTI. When both bits are set to one, the presentation of the WTI is enabled. If the presentation of the WTI remains disabled for the entire WTI grace period, the guest's execution ends without utilizing the WTI, which constitutes an involuntary exit.

During the interpreted execution of the guest CPU, if the guest CPU internally recognizes a host CPU timer external interrupt condition (e.g., an expired time slice) or a priority execution request by the host program (INQUIRY 704), the internal CPU process determines whether warning trace interrupt processing is to be performed before the host receives control (INQUIRY 706). That is, the internal CPU process checks whether the guest is enabled for warning trace processing and, therefore, determines that warning trace processing should be included in the processing to be performed. If warning trace interrupt processing is not to be performed, the interpreted execution of the guest ends (STEP 708) and control returns to the host program (STEP 710). Returning to INQUIRY 706, however, if warning trace interrupt processing is to be performed, the processing is performed (STEP 712), as described in further detail below.

8A to 8C are provided to describe an embodiment of further details of the warning tracking interruption process. In this process, several control indicators including the following are used:

Warning: Internal controls (e.g., G-bit) in effect for the grace period of the trace interrupt facility, which are not architecturally visible but are used by internal CPU logic;

A warning trace interrupt (WTI) present internal control (e.g., P bit) that indicates when 1 that the WTI has been presented to the client and when 0 that the WTI has not been presented. Similar to the internal control in the warning trace interrupt facility grace period, the WTI present internal control is not architecturally visible but is used by internal CPU logic.

Guest-controlled host program priority execution (e.g., T bit), such as a warning trace intervention request indicator in the guest CPU state description; and

When the E indicator is one, there is an enablement of the external interrupt. In one example, the E indicator is a bit within the current program status word (PSW).

8A , in one example, a host CPU timer interrupt condition (e.g., an expired time slice) is identified, or a warning trace intervention request is identified (e.g., the host wishes to return CPU resources early; i.e., before the end of the time slice). If a host CPU timer interrupt condition is identified (INQUIRY 800), a determination is made as to whether the grace period active control indicator is set (e.g., is G equal to 1?) (INQUIRY 802). If G is not set, the G indicator is set to, for example, 1 (STEP 804), and the warning trace interrupt facility grace period begins. The current value of the host CPU timer is then saved (the saved value is referred to herein as the raw value) (STEP 806), and the host CPU timer is set to the warning trace grace period (e.g., 50 microseconds) (STEP 808).

Thereafter, a determination is made as to whether the client is enabled for warning trace interruption (INQUIRY 810). In one embodiment, if client tier 2 is active, indicating that a client has launched another client, then client 2 exits interpret-execute mode with respect to the client 1 interruption and cancels the client 1 "start interpret-execute" instruction. Thus, processing at this point is as client 1. If client 2 is not active, processing continues with client 1 only. If the client is enabled for WTI, a warning trace external interruption (WTI) is presented to the client (STEP 812). In one example, this interruption includes a specific interruption code, which is presented to indicate a grace period for performing one or more functions (e.g., cleanup), if desired.

In addition, P is set to 1, indicating that a WTI has occurred (step 814). Furthermore, the T bit is set to 1 using the interlock update function (the T bit may already be 1 if an intervention request was initially used) (step 816). The grace period in the host CPU timer continues to decrement regardless of whether a WTI has occurred (step 818). The process is then exited (step 820). In one embodiment, the indication of exiting the process indicates that the CPU has completed the current processing of the warning trace interrupt facility and is returning to other processing as indicated by the current state of the CPU.

Returning to query 810, if the client is not enabled for warning tracking interruption, then processing proceeds to step 816. In this example, the client is not enabled for WTI, so WTI cannot be presented to the client. However, the T bit is set to pending so that the T bit can be detected later when the client is indeed enabled for WTI.

Returning to query 800, if it is not a host CPU timer interrupt condition, a warning trace interrupt request is recognized (i.e., host-first execution). That is, the T bit in the intervention request field of the client's status description is 1. Therefore, a determination is made as to whether the G indicator is set (query 850). If the G indicator is not set (e.g., 0), processing continues with step 804. In this case, the condition of T equal to 1 is the initial reason for initiating the WTI procedure. However, if the G bit is set, a determination is made as to whether P is set (query 852). If P is not set (e.g., equal to 0), processing continues with step 810 in an attempt to present a WTI. However, if P is set (e.g., not equal to 0), then the finding of T equal to 1 after the warning trace facility grace period has no effect, and the procedure is exited (step 854).

Returning to query 802, if G is set (e.g., equal to 1), then the guest CPU has been executing within the grace period, and the expiration of the host CPU timer indicates that the grace period has expired. Thus, a WTI cycle has been previously initiated, and the grace period has expired. Therefore, referring to FIG8B, the previously saved original host CPU timer value is decremented by the amount of time actually used during the grace period and then loaded into the host CPU timer (step 860). The interpret execution mode is exited (step 862), and the host CPU timer external interrupt is presented to the host (step 864) (this exit is a form of non-active guest exit).

In addition to the above, WTI analysis can be initiated via certain instructions that may enable the CPU for WTI. For example, referring to FIG. 8C , as described herein, initially, monitoring may be performed for several instructions that enable the CPU for WTI, including: for example, a load PSW (extend) instruction that may set a specified bit in the PSW, followed by a store or system mask instruction, and a "load control" instruction that may set a selected bit in a control register. For example, the T bit for potential warning trace processing may be checked for interrupt-enabled instructions. If T=0 (inquiry 880), then there is no WTI, and the program exits (step 884). However, if T=1, processing continues with inquiry 822.

At query 882, a determination is made as to whether P is set (e.g., equal to 1). If P is set, the process is exited (step 884) since activation has been previously detected. However, if P is not set (e.g., not equal to 1), another determination is made as to whether G is set (e.g., equal to 1) (query 886). If G is not set, processing continues with step 804 (FIG. 8A). However, if G is set (e.g., equal to 1) (step 886 (FIG. 8C)), processing continues with query 810 in FIG. 8A (step 888) and processing is exited.

9 for further details of the handling of the warning trace interrupt. When the guest program receives the warning trace interrupt, the guest program executes any function that the guest program would execute (e.g., an OS function) to, for example, make a dispatchable work unit re-dispatched (step 900). For example, the guest stops the dispatchable unit at a particular point, saves the state of the dispatchable unit, and moves the dispatchable unit to another guest CPU, or enables the dispatchable unit to be moved by providing state information, etc. The guest operating system signals to the host program that the guest operating system has ended (also known as an active exit) by issuing a warning trace cleanup complete signal to the host program (step 902). This signal can be any mechanism that causes the guest operation to give up the remaining time slice. However, the signal is recognized by the host program as the cleanup portion of the protocol. In one example, the cleanup complete function of the diagnostic instruction is used.

If the guest program signals the cleanup completion signal before the grace period expires (INQUIRY 904), the host program remembers the timely exit of the guest CPU (STEP 906). This exit is an active exit. When the guest CPU is next started, the timely nature of the signal is indicated back to the guest CPU (STEP 908). In one example, the guest continues executing the PSW with the PSW set to indicate a success condition code (e.g., condition code 0).

Returning to query 904, if the guest program takes too long for any reason, the grace period expires due to the host CPU timer decrementing the grace period to zero, thus presenting a host CPU timer external interrupt condition to the CPU. In this case, the CPU recognizes that the guest is already within the grace period and does not grant another grace period. Rather, guest execution stops, and control returns to the host program by receiving an external interrupt. The host program recognizes this termination of the guest CPU as an inactive guest exit.

The next time the client CPU is started, the guest operating system can then issue a cleanup complete signal, even though it is now too late. The host program no longer expects to wait for receipt of the cleanup complete signal. Therefore, the late nature of the signal is indicated back to the client CPU the next time the client CPU is started (step 912). In one example, the client continues executing the PSW marked to indicate the late condition that the client will observe the next time it is started. The issuance of a late diagnostic instruction is sometimes referred to as a stale diagnostic instruction because the late diagnostic instruction previously missed exiting within a grace period and then exited later for an undesirable reason.

In one example, after a fresh boot of the guest CPU, the guest program can check the signal-to-continue portion of the protocol to see if the signal was sent within the grace period. The guest program can use this information to investigate why the guest program might be delayed and make improvements to improve statistics for the future.

In one embodiment, when the guest is disabled for all external interrupts, several instructions for external interrupt execution monitoring can be enabled. When the guest is enabled for external interrupts, WTI enable is checked. At this point, if WTI is enabled and the P bit is 0, WTI is presented to the guest CPU.

As mentioned above, in one embodiment, a diagnostic function is used to indicate that cleanup has completed or registered for the warning trace interrupt facility. For cleanup completion, when issued with cleanup parameters and executed, the diagnostic function signals that the issuing CPU has performed any required processing associated with receipt of the warning trace external interrupt. Upon completion, a condition code is set to indicate whether completion was issued within the model-dependent time interval allowed for cleanup following the warning trace interrupt.

Regarding register functions, when issued with register parameters and executed, the diagnostic function signals: a configuration comprehension warning, a trace interrupt, and a success condition code. When the execution is complete, the success condition code is set. The register status is cleared by a system reset.

One embodiment of the format of a diagnostic instruction is described with reference to FIG10 . In one embodiment, diagnostic instruction 1000 includes an operation code 1002 indicating a diagnostic function; a first register field 1004 (R ₁ ); a second register field 1006 (R ₃ ); a general register field 1008 (B ₂ ); and a shift field 1010 (D ₂ ). In one example, the contents of the D ₂ field are added to the contents of general register B ₂ . The result is not used to address data, but rather certain bits (e.g., bits 48 through 63) are used as an opcode extension. When the opcode is extended to a predetermined value, the warning trace cleanup is complete and the time slice is abandoned.

In one example, the _R3 field is unused and contains zeros. Additionally, designated bits of general register _R1 are unused and will contain zeros, and a specific bit of general register _R1 (e.g., bit 63) specifies a cleanup completed function when zero and a register function when one.

In logical partitions that use a shared physical CPU, this feature can improve system performance by allowing the physical CPU on which a logical CPU is executing to be assigned to another logical CPU.

Aside from diagnostics, any other SIE exit (regardless of the reason) during the WTI grace interval similarly restores the original value of the host CPU timer decremented by the amount of grace period time spent.

Described herein in detail is a warning trace interrupt facility that, in one embodiment, provides a mechanism by which a warning trace external interrupt can be presented to CPUs in a configuration with shared CPU resources (such as a logical partition). A control program can use the warning trace external interrupt as a signal to make a currently executing dispatchable unit dispatchable on a different CPU in the configuration.

In one embodiment, a logical (guest) processor executing on a physical processor during a timeslice receives a warning signal indicating a grace period, e.g., the amount of time before the logical processor is to be interrupted (de-assigned from a shareable physical processor), thereby allowing work performed by the logical processor to be completed or moved to another logical processor. As an example, the guest CPU is signaled that its timeslice has expired and that the guest CPU should prioritize executing currently dispatchable work units (DUs) so that they are re-dispatched on another guest CPU. In one example, the warning signal is an interrupt with an interrupt code indicating that the interrupt is a WTI. In another example, the interrupt code includes information regarding the amount of time or other period of time given for the grace period.

In one embodiment, the alert trace interrupt facility may be used in non-virtualized environments as well as virtualized environments where one program and/or processor shares resources (eg, CPU resources or other resources) with one or more other programs and/or processors.

In one embodiment where the environment is a virtual environment, from the client's perspective:

1. The client program observes the installed conditions of the warning tracking interrupt protocol facility.

2. The client program registers for the warning trace interrupt protocol.

3. The client CPU receives warning tracking notifications based on the specific architecture (e.g., shared memory indication, shared I/O device indication, interrupt).

4. The guest program executing on the guest CPU performs applicable processing according to the nature of the guest program that has received the notification (it is expected that the processing of the notification is unique to each operating system).

5. The client CPU actively relinquishes control based on the warning tracking protocol technology.

6. The next time the client CPU is started, the client program can observe the feedback according to the warning tracking protocol.

Additionally, in one embodiment, from the host's perspective:

A. The client program observes the installed conditions of the warning tracking interrupt protocol facility.

1. The host program obtains an indication that a warning trace interrupt protocol facility has been installed.

2. The host program permanently remembers the installed status of the warning tracking interrupt protocol.

3. The host program indicates to each client configuration that the warning tracking protocol has been installed.

4. The host program disables the warning tracking protocol in all unregistered guest CPUs.

5. The host program is prepared to recognize client alert tracking registration requests from each client configuration.

B. The host program recognizes the warning tracking registration request from the client.

1. The host program persistently remembers the client configuration and understands the warning tracking protocol.

2. The host program enables the client for the alert tracking protocol.

C. During normal guest CPU X operation, use the priority execution of guest CPU X to reacquire the corresponding host CPU X.

1. The host program in CPU Y sends a signal to the guest CPU X.

a. According to the alert tracking protocol, CPU X propagates the notification to guest CPU X via an update of a shared memory location, an update of a shared I/O device, or an interrupt to guest CPU X.

D. Guest CPU X halts, returning control to host CPU X.

1. If within the grace period, the host process on CPU X observes the active guest exit according to the alert tracking protocol and remembers the good feedback for the next boot of guest CPU X, regardless of which host CPU may have deployed guest CPU X at that time.

a. If within the grace period, but the exit of guest CPU X is not based on the warning tracking protocol, the feedback status is not remembered.

2. If not within the grace period, the host process on CPU X observes the active guest exit according to the warning tracking protocol and remembers the bad feedback for the next startup of guest CPU X, regardless of which host CPU may have deployed guest CPU X at that time.

a. If it is not within the grace period, but the exit of guest CPU X is not based on the warning tracking protocol, the feedback status is not remembered.

3. The host program on host CPU X redirects CPU X to a priority execution assignment.

E. If the feedback status is remembered, no matter which host CPU deploys the guest CPU X, the next sequential startup of the guest CPU X sets the feedback indication according to the warning tracking protocol before starting the guest CPU X.

In one embodiment, a client processor configured in a client receives a unique interrupt defined for the computer architecture, which is a warning trace interrupt. The interrupt indicates a specific code identifying the interrupt as a warning trace interrupt. The interrupt implies a relatively short time interval, referred to as a grace period, which gradually leads to the termination of the client processor execution.

During the grace period, in one example, the guest program is nominally expected to make the currently dispatchable work unit re-dispatched on another guest processor, thus avoiding being stuck on the current guest processor waiting for its next normal time slice start from the host.

In one example, a relatively short time interval is granted only once per host program launch to the guest processor. The time interval is granted, for example, from an existing time interval in which the guest processor is currently executing. Because the granted time interval is allocated from the normal remaining time slice, the time interval does not essentially borrow time, but rather uses a constrained amount of time from the current time interval to ensure that the guest processor is prioritized for a relatively short period of time.

In another example where the current time slice has expired, a time interval is granted as additional time in addition to the existing time interval in which the guest processor is currently executing. The host program considers the granted time interval against the next expected sequential normal time interval to be consumed by the guest processor, which is expected to be executed next by the guest processor. This is still intended to ensure that the guest processor is indeed prioritized for a relatively short period of time.

In one example, an interrupt request for a warning trace event may be generated to inform a program that it is nearing the end of its current execution interval on a shared CPU. An interrupt request is a pending condition type generated when a configuration is registered and enabled for the warning trace interrupt facility.

Cooperative processing between programs (e.g., host and guest) optimizes resource sharing (e.g., CPU) between programs (e.g., guest operating systems). One or more aspects provide, for example, better response times with equal CPU utilization. Additionally, system serialization is freed up before the hypervisor dispatches.

In another embodiment, one or more aspects of the present invention can be used to request from an operating system to allow individual threads to continue to improve the elapsed time of time-sensitive work. That is, a thread can request additional time or be provided with additional time to perform a function.

As will be appreciated by those skilled in the art, one or more aspects of the present invention may be embodied as a system, method, or computer program product. Thus, one or more aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may generally be referred to herein as a "circuit," "module," or "system." Furthermore, one or more aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

Any combination of one or more computer-readable media may be utilized. A computer-readable medium may be a computer-readable storage medium. For example, a computer-readable storage medium may be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer-readable storage media include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device.

11 , in one example, a computer program product 1100 includes, for example, one or more non-transitory computer-readable storage media 1102 to store computer-readable program code means or logic 1104 thereon to provide and facilitate one or more aspects of the present invention.

Program code embodied on a computer-readable medium may be transmitted using an appropriate medium, including but not limited to wireless media, wired media, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for performing the operations of one or more aspects of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, Smalltalk, C++, or the like, and conventional procedural programming languages such as the "C" programming language, an assembler, or similar programming languages. The program code may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In scenarios where execution occurs entirely on a remote computer or server, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

One or more aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each block of these flowchart illustrations and/or block diagrams, and combinations of blocks in these flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce means for implementing the functions/actions specified in the flowchart(s) and/or block diagram(s).

These computer program instructions may also be stored in a computer-readable medium, which can direct a computer, other programmable data processing apparatus or other device to function in a specific manner, so that the instructions stored in the computer-readable medium produce a manufactured object that includes instructions for implementing the functions/actions specified in the one or more flowcharts and/or block diagram blocks.

These computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are executed on the computer, other programmable apparatus, or other device to produce a computer-implemented program, so that the instructions executed on the computer or other programmable apparatus provide a program for implementing the functions/actions specified in the flowchart(s) and/or block diagram(s).

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementation schemes of the systems, methods, and computer program products of various embodiments according to one or more aspects of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of program code that includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative embodiments, the functions annotated in the blocks may not occur in the order annotated in the figures. For example, depending on the functionality involved, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in the reverse order. It should also be noted that each block of the block diagram and/or flowchart illustration and the combination of blocks in the block diagram and/or flowchart illustration may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions that performs the specified function or action.

In addition to the above, one or more aspects of the present invention may also be provided, supplied, deployed, managed, serviced, etc., by a service provider that provides management of a customer environment. For example, a service provider may generate, maintain, support, etc., computer program code and/or computer infrastructure that implements one or more aspects of the present invention for one or more customers. In return, the service provider may receive payment from the customer under a subscription and/or fee agreement, for example. Alternatively or additionally, the service provider may receive payment from the sale of advertising content to one or more third parties.

In one aspect of the present invention, an application program may be deployed to perform one or more aspects of the present invention. As an example, deployment of the application program includes providing a computer infrastructure operable to perform one or more aspects of the present invention.

As another aspect of the present invention, a computer infrastructure may be deployed that includes integrating computer-readable program code into a computing system, wherein the program code in combination with the computing system is capable of performing one or more aspects of the present invention.

As another aspect of the present invention, a program for integrating a computer infrastructure may be provided, comprising integrating computer-readable program code into a computer system. The computer system may include a computer-readable medium, wherein the computer medium includes one or more aspects of the present invention. The program code combined with the computer system may be capable of performing one or more aspects of the present invention.

While various embodiments have been described above, these embodiments are merely examples. For example, computing environments of other architectures may incorporate and utilize one or more aspects of the present invention. Furthermore, the grace period may be other than an amount of time, such as the number of instructions or cycles, or any other quantifiable value. Numerous changes and/or additions may be made without departing from the spirit of the present invention.

In addition, other types of computing environments may benefit from one or more aspects of the present invention. As an example, a data processing system suitable for storing and/or executing program code is available, which includes at least two processors coupled directly or indirectly via a system bus to memory components. The memory components include, for example, local memory used during actual execution of the program code, mass storage, and cache memory that provides temporary storage for at least some program code in order to reduce the number of times the program code must be retrieved from the mass storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, DASDs, tapes, CDs, DVDs, thumb drives, and other memory media) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the available types of network adapters.

Other examples of computing environments that can contain and/or use one or more aspects of the present invention are described below.

Referring to FIG. 12 , representative components of a host computer system 5000 implementing one or more aspects of the present invention are depicted. The representative host computer 5000 includes one or more CPUs 5001 in communication with computer memory (i.e., central storage) 5002, and I/O interfaces to storage media devices 5011 and networks 5010 for communicating with other computers or SANs and the like. The CPUs 5001 conform to an architecture having a structured instruction set and structured functionality. The CPUs 5001 may have a dynamic address translation (DAT) 5003 for translating program addresses (virtual addresses) into real addresses in memory. The DAT typically includes a translation lookaside buffer (TLB) 5007 for caching translations so that later accesses to blocks of computer memory 5002 do not require the delay of address translation. Typically, a cache 5009 is used between the computer memory 5002 and the processors 5001. Cache 5009 can be a hierarchical cache, with a large cache available to more than one CPU and smaller, faster (lower-level) caches between the large cache and each CPU. In some embodiments, the lower-level caches are split to provide separate low-level caches for instruction fetches and data access. In one embodiment, instructions are fetched from memory 5002 via cache 5009 by instruction fetch unit 5004. Instructions are decoded in instruction decode unit 5006 and dispatched (in some embodiments, along with other instructions) to instruction execution unit 5008. Typically, several execution units 5008 are used, such as an arithmetic execution unit, a floating-point execution unit, and a branch instruction execution unit. Instructions are executed by the execution units, accessing operands from registers or memory specified by the instruction as needed. If operands are to be accessed (loaded or stored) from memory 5002, the load/store unit 5005 typically handles the access under the control of the instruction being executed. Instructions may be executed in hardware circuitry or in internal microcode (firmware), or by a combination of both.

As noted, a computer system includes information in local (or main) storage, as well as addressing, protection, and reference and change logging. Some aspects of addressing include the format of addresses, the concept of address space, the various types of addresses, and the manner in which addresses of one type are translated into addresses of another type. Some of the storage in main storage includes permanently assigned storage addresses. Main storage provides the system with directly addressable, fast-access storage of data. Both data and programs are loaded into main storage (from input devices) before they can be processed.

Main storage may include one or more smaller, faster-access buffer memories, sometimes called caches. Caches are typically physically associated with a CPU or I/O processor. Aside from performance, the effects of the physical construction and use of different storage media are generally unobservable to the program.

Separate caches may be maintained for instructions and for data operands. Information within the cache is maintained as contiguous bytes on general boundaries called cache blocks or cache lines (or simply lines). The model provides a "Get Cache Attributes" command that returns the size of a cache line in bytes. The model also provides "Prefetch Data" and "Prefetch Data Relative Length" commands, which implement prefetches from memory into the data or instruction cache or releases data from the cache.

Storage is viewed as a long horizontal string of bits. For most operations, storage is accessed in a left-to-right sequence. The bit string is further divided into units of eight bits. Eight-bit units are called bytes, and bytes are the basic building blocks of all information formats. Each byte position in storage is identified by a unique non-negative integer, which is the address of that byte position, or simply the byte address. Adjacent byte positions have consecutive addresses, starting with 0 on the left and proceeding in a left-to-right sequence. Addresses are unsigned binary integers and are 24, 31, or 64 bits.

Information is transferred between storage and the CPU or channel subsystem one byte or group of bytes at a time. Unless otherwise specified, a group of bytes in storage is addressed by the leftmost byte of the group, such as in . The number of bytes in a group is specified implicitly or explicitly by the operation to be performed. When used in CPU operations, a group of bytes is called a field. Within each group of bytes, such as in , the bits are numbered in a sequence from left to right. In , the leftmost bit is sometimes called the "high-order" bit, and the rightmost bit is called the "low-order" bit. However, the bit number is not a storage address. Only bytes can be addressed. To operate on individual bits of a byte in storage, the entire byte is accessed. The bits in a byte are numbered from left to right 0 to 7 (e.g., in ). The bits in an address may be numbered 8 to 31 or 40 to 63 for a 24-bit address, or 1 to 31 or 33 to 63 for a 31-bit address; the bits in an address are numbered 0 to 63 for a 64-bit address. In any other fixed-length format of multiple bytes, the bits comprising the format are numbered consecutively starting at 0. For error detection purposes, and preferably for correction, one or more check bits may be transmitted with each byte or group of bytes. These check bits are automatically generated by the machine and are not directly programmable. Storage capacity is expressed in terms of the number of bytes. When the length of a storage operand field is implied by the instruction's opcode, the field is said to have a fixed length, which may be one, two, four, eight, or sixteen bytes. Larger fields may be implied for some instructions. When the length of a storage operand field is not implied but explicitly stated, the field is said to have a variable length. The length of a variable-length operand can vary in increments of one byte (or, with some instructions, in multiples of two bytes or other multiples). When information is placed in storage, the contents of only those byte locations included in the specified field are replaced, even though the width of the physical path to storage may be greater than the length of the field being stored.

Certain units of information will be at integral boundaries in storage. When a storage address is a multiple of a length in bytes, the boundary is referred to as integral for the unit of information. Special names are given to fields of 2, 4, 8, and 16 bytes on integral boundaries. A halfword is a group of two consecutive bytes on a two-byte boundary and is the basic building block of instructions. A word is a group of four consecutive bytes on a four-byte boundary. A doubleword is a group of eight consecutive bytes on an eight-byte boundary. A quadword is a group of 16 consecutive bytes on a 16-byte boundary. When a storage address specifies a halfword, word, doubleword, and quadword, the binary representation of the address contains one, two, three, or four rightmost zero bits, respectively. Instructions will be on two-byte integral boundaries. The storage operands of most instructions do not have boundary alignment requirements.

On devices that implement separate caches for instructions and data operands, significant delays may be experienced if a program is stored to a cache line from which instructions are subsequently fetched, regardless of whether the store changes the subsequently fetched instructions.

In one embodiment, the present invention may be implemented using software (sometimes referred to as authorized internal code, firmware, microcode, millicode, picocode, and the like, any of which may be consistent with one or more aspects of the present invention). Referring to FIG. 12 , software program code embodying one or more aspects of the present invention may be accessed by a processor 5001 of a host system 5000 from a long-term storage medium device 5011, such as a CD-ROM drive, tape drive, or hard drive. The software program code may be embodied on any of a variety of known media for use by a data processing system, such as a disk, hard drive, or CD-ROM. The program code may be distributed on these media, or may be distributed to users from computer memory 5002 or from the storage of one computer system to other computer systems via a network 5010 for use by users of those other systems.

The software program code includes an operating system that controls the functions and interactions of various computer components and one or more application programs. The program code is typically paged from the storage medium device 5011 to a relatively high-speed computer memory 5002 where the program code is available for processing by the processor 5001. The techniques and methods for embodying software program code in memory, on physical media, and/or distributing software program code over a network are well known and will not be discussed further herein. When program code is generated and stored on tangible media (including but not limited to electronic memory modules (RAM), flash memory, compact discs (CDs), DVDs, magnetic tapes, and the like), it is often referred to as a "computer program product." The computer program product medium is typically readable by processing circuitry in a preferred computer system for execution by the processing circuitry.

FIG13 illustrates a representative workstation or server hardware system in which one or more aspects of the present invention may be practiced. The system 5020 of FIG13 includes a representative underlying computer system 5021, such as a personal computer, workstation, or server, including optional peripheral devices. The underlying computer system 5021 includes one or more processors 5026 and a bus for connecting and enabling communication between the processors 5026 and other components of the system 5021 according to known techniques. For example, the bus connects the processor 5026 to a memory 5025 and to long-term storage 5027, which may include a hard drive (including, for example, any of magnetic media, CDs, DVDs, and flash memory) or a tape drive. The system 5021 may also include a user interface adapter that connects the microprocessor 5026 to one or more interface devices (such as a keyboard 5024, a mouse 5023, a printer/scanner 5030, and/or other interface devices) via the bus. These interface devices can be any user interface device such as a touch-sensitive screen, a digitizing entry pad, etc. The bus also connects a display device 5022 such as an LCD screen or monitor to the microprocessor 5026 via a display adapter.

System 5021 can communicate with other computers or networks of computers by means of a network adapter capable of communicating with network 5029 (5028). Example network adapters are communication channels, token rings, Ethernet networks, or modems. Alternatively, system 5021 can communicate using a wireless interface such as a Cellular Digital Packet Data (CDPD) card. System 5021 can be associated with these other computers in a local area network (LAN) or wide area network (WAN), or system 5021 can be a client in a client/server configuration with another computer, etc. All of these configurations and appropriate communication hardware and software are known in the art.

FIG14 illustrates a data processing network 5040 in which one or more aspects of the present invention may be practiced. The data processing network 5040 may include a plurality of individual networks, such as wireless networks and wired networks, each of which may include a plurality of individual workstations 5041, 5042, 5043, 5044. Additionally, as will be appreciated by those skilled in the art, one or more LANs may be included, wherein the LANs may include a plurality of intelligent workstations coupled to a host processor.

Still referring to FIG. 14 , the network may also include mainframe computers or servers, such as a gateway computer (client server 5046) or an application server (a remote server 5048 that can access a data repository and can also be accessed directly from a workstation 5045). The gateway computer 5046 serves as an entry point into each individual network. A gateway is required when connecting one network protocol to another. The gateway 5046 can preferably be coupled to another network (e.g., the Internet 5047) via a communication link. The gateway 5046 can also be directly coupled to one or more workstations 5041, 5042, 5043, 5044 using a communication link. The gateway computer can be implemented using an IBM eServer ^™ server available from International Business Machines Corporation.

13 and 14 , software programming code that may embody one or more aspects of the present invention may be accessed by processor 5026 of system 5020 from a long-term storage medium 5027, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use by a data processing system, such as a disk, hard drive, or CD-ROM. The program code may be distributed on these media, or may be distributed from memory to users 5050, 5051, or distributed from the storage of one computer system to other computer systems via a network for use by users of these other systems.

Alternatively, the programming code may be embodied in memory 5025 and accessed by processor 5026 using a processor bus. This programming code includes an operating system that controls the functions and interactions of various computer components and one or more application programs 5032. Program code is typically paged from storage medium 5027 to high-speed memory 5025 where the program code is available for processing by processor 5026. Techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software programming code over a network are well known and will not be discussed further herein. Program code, when generated and stored on tangible media (including but not limited to electronic memory modules (RAM), flash memory, compact disks (CDs), DVDs, magnetic tapes, and the like), is often referred to as a "computer program product." The computer program product media is typically readable by processing circuitry in a preferred computer system for execution by the processing circuitry.

The cache most readily available to the processor (usually faster and smaller than the processor's other caches) is the lowest (L1 or level one) cache, with main storage (main memory) being the highest level cache (L3 if there are three levels). The lowest level cache is often divided into an instruction cache (I-cache), which holds machine instructions to be executed, and a data cache (D-cache), which holds data operands.

Referring to FIG. 15 , an exemplary processor embodiment is depicted for processor 5026. Typically, one or more levels of cache 5053 are used to buffer memory blocks to improve processor performance. Cache 5053 is a high-speed buffer that holds cache lines of memory data that are most likely to be used. Typical cache lines are 64, 128, or 256 bytes of memory data. In addition to being used to cache data, separate caches are often used to cache instructions. Cache coherency (synchronizing copies of lines in memory and cache) is often provided by various "snoop" algorithms well known in the art. The main memory storage 5025 of a processor system is often referred to as a cache. In processor systems with four levels of cache 5053, the main storage 5025 is sometimes referred to as a level 5 (L5) cache because it is typically faster and only holds a portion of the non-volatile storage (DASD, tape, etc.) available to the computer system. Main storage 5025 "caches" pages of data that are paged in and out of main storage 5025 by the operating system.

The program counter (instruction counter) 5061 tracks the address of the current instruction to be executed. The program counter in the processor is 64 bits and can be truncated to 31 or 24 bits to support previous addressing restrictions. The program counter is usually embodied in the computer's program status word (PSW), so that the program counter persists during context switches. Therefore, a running program with a program counter value can be interrupted by, for example, the operating system (context switch from the program environment to the operating system environment). The program's PSW maintains the program counter value when the program is not active, and uses the operating system's program counter (in the PSW) when the operating system is executing. Typically, the program counter is incremented by an amount equal to the number of bytes of the current instruction. Reduced Instruction Set Computing (RISC) instructions are usually fixed in length, while Complex Instruction Set Computing (CISC) instructions are usually variable in length. IBM instructions are CISC instructions with a length of 2, 4, or 6 bytes. For example, the program counter 5061 is modified by a context switch operation or a branch token operation of a branch instruction. In a context switch operation, the current program counter value is saved in the program status word along with other state information about the executing program (such as condition codes), and a new program counter value is loaded to point to the instructions of the new program module to be executed. A branch token operation is performed to allow the program to make decisions or loop within the program by loading the result of the branch instruction into the program counter 5061.

Typically, the instruction fetch unit 5055 is used to fetch instructions on behalf of the processor 5026. The fetch unit fetches the "next sequential instruction" after a context switch, the target instruction of a branch token instruction, or the first instruction of a program. Modern instruction fetch units often use prefetching techniques to speculatively fetch instructions based on the likelihood that the prefetched instruction will be used. For example, the fetch unit may fetch 16 bytes of the instruction that includes the next sequential instruction and additional bytes for other sequential instructions.

The fetched instruction is then executed by the processor 5026. In one embodiment, the fetched instruction is passed to the dispatch unit 5056 of the fetch unit. The dispatch unit decodes the instruction and passes information about the decoded instruction to the appropriate units 5057, 5058, 5060. The execution unit 5057 will typically receive information about the decoded arithmetic instruction from the instruction fetch unit 5055 and will perform arithmetic operations on the operands according to the instruction's operation code. The operands are preferably provided to the execution unit 5057 from memory 5025, architected registers 5059, or from the immediate fields of the instruction being executed. The results of the execution, when stored, are stored in memory 5025, registers 5059, or other machine hardware (such as control registers, PSW registers, and the like).

The processor 5026 typically has one or more units 5057, 5058, and 5060 for executing instructions. Referring to FIG. 16A , the execution unit 5057 can communicate with architected general registers 5059, the decode/dispatch unit 5056, the load/store unit 5060, and other processor units 5065 via interface logic 5071. The execution unit 5057 can use several register circuits 5067, 5068, and 5069 to hold information for operations to be performed by the arithmetic logic unit (ALU) 5066. The ALU performs arithmetic operations such as addition, subtraction, multiplication, and division, as well as logical functions such as AND, OR, and XOR, rotates, and shifts. Preferably, the ALU supports specialized operations for design dependencies. For example, other circuitry may provide other architected facilities 5072, including conditional codes and repair support logic. Typically, the results of the ALU operations are held in output register circuitry 5070, which can forward the results to various other processing functions. Many configurations of processor units exist, but this description is intended to provide a representative understanding of one embodiment.

For example, an add (ADD) instruction will be executed in an execution unit 5057 having arithmetic and logical functionality, while a floating-point instruction, for example, will be executed in a floating-point execution unit having dedicated floating-point capabilities. Preferably, the execution unit operates on operands by performing a function defined by the operation code on the operands identified by the instruction. For example, an add (ADD) instruction may be executed by the execution unit 5057 on operands found in two registers 5059 identified by the register field of the instruction.

Execution unit 5057 performs arithmetic addition on two operands and stores the result in a third operand, which may be a third register or one of the two source registers. The execution unit preferably utilizes an arithmetic logic unit (ALU) 5066, which is capable of performing a variety of logical functions such as shifts, rotations, AND, OR, and XOR, as well as a variety of algebraic functions including addition, subtraction, multiplication, and division. Some ALUs 5066 are designed for scalar operations, and some are designed for floating point. Depending on the architecture, data may be in big endian (with the least significant byte at the highest byte address) or little endian (with the least significant byte at the lowest byte address). IBM is big endian. Signed fields may be both sign and magnitude (1's complement or 2's complement), depending on the architecture. Two's complement is advantageous because the ALU does not need to be designed with subtraction capabilities, since negative or positive values in two's complement only require additions within the ALU. For example, numbers are often described using a shorthand notation where a 12-bit field defines the address of a 4,096-byte block, and are typically described as 4Kbyte blocks.

Referring to FIG. 16B , branch instruction information for executing a branch instruction is typically sent to a branch unit 5058 . The branch unit 5058 often uses a branch prediction algorithm, such as a branch history table 5082 , to predict the outcome of the branch before other conditional operations are completed. The target of the current branch instruction is extracted and speculatively executed before the conditional operations are completed. When the conditional operations are completed, the speculatively executed branch instruction is either completed or discarded based on the conditional operation and the speculative outcome. A typical branch instruction tests a condition code and branches to a target address if the condition code satisfies the branch instruction's branch requirements. The target address may be calculated based on a number (including one) found in, for example, a register field or a real field of the instruction. The branch unit 5058 may utilize an ALU 5074 having multiple input register circuits 5075 , 5076 , 5077 , and an output register circuit 5080 . For example, the branch unit 5058 may communicate with general registers 5059 , a decode dispatch unit 5056 , or other circuits 5073 .

For example, the execution of a group of instructions may be interrupted for a variety of reasons, including a context switch initiated by the operating system, a program exception or error that causes a context switch, an I/O interrupt signal that causes a context switch, or multi-threaded activity of multiple programs (in a multi-threaded environment). Preferably, the context switch action saves information about the currently executing program and then loads state information about the calling program. For example, the state information may be saved in hardware registers or in memory. The state information preferably includes a program counter value pointing to the next instruction to be executed, condition codes, memory translation information, and architected register contents. The context switch activity may be initiated by hardware circuitry, application programs, operating system programs, or firmware code (microcode, picocode, or Licensed Internal Code (LIC)), alone or in combination.

The processor accesses operands according to the method defined by the instruction. An instruction may use the value of a portion of the instruction to provide a real operand, may provide one or more register fields that explicitly point to general registers or special registers (e.g., floating-point registers). An instruction may utilize an implicit register identified by the operation code field as an operand. An instruction may use a memory location for an operand. The memory location of an operand may be provided by a register, a real field, or a combination of a register and a real field, as exemplified by a long displacement facility, where the instruction defines a base register, an index register, and a real field (displacement field), which are added together to provide, for example, the address of the operand in memory. Unless otherwise indicated, a location herein generally implies a location in main memory (primary storage).

16C , the processor accesses memory using a load/store unit 5060. The load/store unit 5060 can perform a load operation by obtaining the address of a target operand in memory 5053 and loading the operand into a register 5059 or another memory 5053 location, or can perform a store operation by obtaining the address of a target operand in memory 5053 and storing data obtained from a register 5059 or another memory 5053 location in the target operand location in memory 5053. The load/store unit 5060 can be speculative and can access memory in an out-of-order sequence relative to the instruction sequence; however, the load/store unit 5060 maintains the appearance to the program of executing instructions in order. The load/store unit 5060 can communicate with general registers 5059, decode/dispatch unit 5056, cache/memory interface 5053, or other components 5083, and includes various register circuits, ALU 5085, and control logic 5090 to calculate store addresses and provide pipeline sequencing to keep operations in order. Some operations may be out of order, but the load/store unit provides functionality that makes out-of-order operations appear to the program to have been executed in order, as is well known in the art.

Preferably, the addresses that an application "sees" are often referred to as virtual addresses. Virtual addresses are sometimes referred to as "logical addresses" and "effective addresses." These virtual addresses are virtual in that they are redirected to physical memory locations using one of a variety of dynamic address translation (DAT) techniques, including (but not limited to) simply prefixing the virtual address with an offset value, translating the virtual address through one or more translation tables, the translation tables preferably including, alone or in combination, at least one segment table and a page table, preferably the segment table having entries pointing to the page table. In, a translation hierarchy is provided, including a region first table, a region second table, a region third table, a segment table, and an optional page table. The performance of address translation is often improved by utilizing a translation lookaside buffer (TLB), which contains entries that map virtual addresses to associated physical memory locations. These entries are generated when the DAT uses the translation tables to translate virtual addresses. Subsequent uses of the virtual address can then utilize an entry of the fast TLB rather than a slow sequential translation table access.The TLB contents can be managed by a variety of replacement algorithms including Least Recently Used (LRU).

In the case where the processor is a processor of a multi-processor system, each processor has the responsibility to keep shared resources such as I/O, cache, TLB, and memory interlocked to achieve consistency. Typically, "snooping" technology will be used to maintain cache coherence. In a snooping environment, each cache line can be marked as being in any of the following states: shared, exclusive, changed, invalid, and the like to facilitate sharing.

For example, I/O unit 5054 ( FIG. 15 ) provides the processor with a means for attaching to peripheral devices including tape, optical disks, printers, displays, and networks. I/O units are often presented to computer programs by software drivers. In mainframe computers, such as those available from [ 00155 ], channel adapters and open system adapters are I/O units that provide communication between the mainframe computer's operating system and peripheral devices.

In addition, other types of computing environments may benefit from one or more aspects of the present invention. As an example, as mentioned herein, an environment may include an emulator (e.g., software or other emulation mechanisms) in which a specific architecture (including, for example, instruction execution, constructed functions such as address translation, and constructed registers) or a subset thereof (e.g., on a native computer system with a processor and memory) is emulated. In this environment, one or more emulation functions of the emulator may implement one or more aspects of the present invention, even if the computer executing the emulator may have an architecture different from the capability being emulated. As an example, in emulation mode, a specific instruction or the operation being emulated is decoded, and appropriate emulation functions are set up to implement individual instructions or operations.

In an emulation environment, a host computer, for example, includes: a memory that stores instructions and data; an instruction fetch unit that fetches instructions from memory and, if appropriate, provides local buffering of the fetched instructions; an instruction decode unit that receives the fetched instructions and determines the type of instruction fetched; and an instruction execution unit that executes the instructions. Execution may include loading data from memory into registers; storing data from registers back to memory; or performing some type of arithmetic or logical operation (as determined by the decode unit). In one embodiment, each unit is implemented in software. For example, the operations performed by these units are implemented as one or more subroutines within the emulator software.

More specifically, in mainframe computers, constructed machine instructions are often made available to programmers (typically "C" programmers today) by means of compiled applications. These instructions, stored on a storage medium, can be executed natively in a server or in a machine running another architecture. Instructions can be emulated in existing and future mainframe computer servers and on other machines (e.g., Power System servers and servers). Instructions can be executed in machines running Linux on a wide variety of machines using hardware manufactured by AMD ^™ and other manufacturers. In addition to executing on this hardware, Linux can also be used and machines using emulations performed by Hercules, UMX, or FSI (Fundamental Software, Inc.), where execution is generally in emulation mode. In emulation mode, emulation software is executed by the native processor to emulate the architecture of the emulated processor.

Native processors typically run emulation software, which includes firmware or a native operating system to perform the simulation of the emulated processor. The emulation software is responsible for extracting and executing instructions of the emulated processor architecture. The emulation software maintains an emulation program counter to track instruction boundaries. The emulation software can extract one or more emulated machine instructions at a time and convert them into a group of corresponding native machine instructions for execution by the native processor. These converted instructions can be cached, allowing for faster conversion. Despite this, the emulation software still maintains the architectural rules of the emulated processor architecture to ensure that operating systems and applications written for the emulated processor operate correctly. In addition, the emulation software will provide resources identified by the emulated processor architecture so that operating systems or applications designed to run on the emulated processor can be executed on the native processor with the emulation software. These resources include (but are not limited to) control registers, general registers, floating-point registers, dynamic address translation functions including, for example, segment tables and page tables, interrupt mechanisms, context switching mechanisms, time of day (TOD) clocks, and constructed interfaces to the I/O subsystem.

The specified instruction being emulated is decoded and a subroutine is called to perform the function of the respective instruction. The emulation software function that emulates the function of the emulated processor is implemented, for example, as a "C" subroutine or driver, or some other method of providing a driver for the specified hardware that will be within the skill of those skilled in the art after understanding the description of the preferred embodiment. Various software and hardware emulation patents, including but not limited to, the following, describe known ways to achieve instruction formats for different machine architectures for emulation of target machines that are available to those skilled in the art: U.S. Patent No. 5,551,013 to Beausoleil et al., entitled “Multiprocessor for Hardware Emulation”; and U.S. Patent No. 6,009,261 to Scalzi et al., entitled “Preprocessing of Stored Target Routines for Emulating Incompatible Instructions on a Target Processor”; and U.S. Patent No. 5,574,873 to Davidian et al., entitled “Decoding Guest Instruction to Directly Access Emulation Routines that Emulate the Guest Instructions”; and U.S. Patent No. 6,308,255 to Gorishek et al., entitled “Symmetrical Multiprocessing Bus and Chipset Used for Coprocessor Support Allowing Non-Native Code to Run in a System”; and Lethin et al., entitled “Dynamic Optimizing Object Code Translator for Architecture Emulation and Dynamic Optimizing Object Code Translation Method”; and U.S. Patent No. 5,790,825 to Eric Traut, entitled “Method for Emulating Guest Instructions on a Host Computer Through Dynamic Recompilation of Host Instructions,” each of which is hereby incorporated by reference in its entirety; and numerous other patents.

FIG17 illustrates an example of an emulated host computer system 5092 that emulates a host computer system 5000′ based on a host architecture. In emulated host computer system 5092, host processor (CPU) 5091 is an emulated host processor (or virtual host processor) and includes an emulated processor 5093 having a native instruction set architecture that is different from the native instruction set architecture of processor 5091 of host computer 5000′. Emulated host computer system 5092 has memory 5094 accessible to emulated processor 5093. In the example embodiment, memory 5094 is partitioned into a host computer memory portion 5096 and an emulated routine portion 5097. Host computer memory 5096 is available for programs in emulated host computer 5092 based on the host computer architecture. The emulation processor 5093 executes native instructions of a constructed instruction set for an architecture different from that of the emulation processor 5091. These native instructions are obtained from the emulation routine memory 5097 and can access host instructions for execution from a program in the host computer memory 5096 using one or more instructions obtained in the sequence and access/decode routine. The sequence and access/decode routine can decode the accessed host instructions to determine a native instruction execution routine for emulating the function of the accessed host instructions. For example, other facilities defined for the architecture of the host computer system 5000' can be emulated using the constructed facility routines, including facilities such as general registers, control registers, dynamic address translation, I/O subsystem support, and processor cache. The emulation routine can also utilize functions available in the emulation processor 5093 (such as general registers and dynamic translation of virtual addresses) to improve the performance of the emulation routine. Specialized hardware and offload engines can also be provided to assist the processor 5093 in emulating the functions of the host computer 5000'.

The terms used herein are for the purpose of describing specific embodiments only and are not intended to limit the present invention. As used herein, unless the context clearly indicates otherwise, the singular forms "a," "an," and "the" are intended to include the plural forms as well. It should be further understood that when the term "comprising" is used in this specification, it specifies the presence of the stated features, integers, steps, operations, components, and/or elements, but does not preclude the presence or addition of one or more other features, integers, steps, operations, components, elements, and/or groups thereof.

The corresponding structures, materials, actions and equivalents (if any) of all members or step-plus-function components in the scope of the following claims are intended to include any structure, material or action for performing functions in combination with other claimed components as specifically claimed. A description of one or more aspects of the present invention has been presented for the purpose of illustration and description, but the description is not intended to be exhaustive or to limit the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiments are selected and described in order to best explain the principles and practical applications of the invention and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suitable for the specific purposes contemplated.

Claims (17)

1. An apparatus for facilitating processing in a computing environment, the apparatus comprising: A module of a second program provides an indication that a warning tracking facility has been installed in the computing environment by a first program, and the warning tracking facility provides the second program with a grace period to perform the first function; The module that notifies the second program of the commencement of the grace period described in the first procedure; and After the grace period, the module that performs the second function is executed by the first program. The device also includes a module that receives a warning tracking registration request from a second program via a first program and enables the second program to participate in the warning tracking facility. 2. The apparatus of claim 1, wherein the execution of the second function is provided by the first program to the second program with a status indication related to the completion of the first function within the grace period. 3. The apparatus of claim 2, wherein providing the status indication comprises: when the second program is executed next, the first program provides the second program with an indication that the first function was completed during the grace period. 4. The apparatus of claim 2, wherein providing the status indication comprises: when the second program is executed next, the first program provides the second program with an indication that the first function was not completed during the grace period. 5. The apparatus of claim 1, wherein the first program is a host program and the second program is a client program, wherein the client program accesses shared resources of the computing environment during a time slice provided to a client central processing unit executing the client program, the grace period being distinct from the time slice. 6. The apparatus of claim 5, wherein the grace period causes the time slice to terminate prematurely. 7. The apparatus of claim 5, wherein, in addition to the time slice, the grace period also provides a time period for performing the first function. 8. The apparatus of claim 1, wherein the first function comprises one of the following: A dispatchable unit that completes execution on a processor on which a second program is executed; or This allows the dispatchable unit to be reassigned on another processor in the computing environment. 9. The apparatus of claim 1, wherein the notification includes causing an interruption in which shared resources assigned to the second program are released after the grace period expires. 10. A computer system for facilitating processing in a computing environment, the computer system comprising: Memory; and A processor communicating with the memory, wherein the computer system is configured to execute a method comprising: The first program provides a second program with an indication that the warning tracking facility has been installed in the computing environment, and the warning tracking facility provides the second program with a grace period to perform the first function; The first procedure notifies the second procedure that the grace period has commenced; and After the grace period, the first procedure will perform the second function. The first procedure receives the warning tracking registration request from the second procedure and activates the second procedure to participate in the warning tracking facility. 11. The computer system of claim 10, wherein performing the second function comprises: providing a status indication from the first program to the second program related to the completion of the first function within the grace period. 12. The computer system of claim 10, wherein the first program is a host program and the second program is a client program, wherein the client program is able to access shared resources of the computing environment during a time slice provided to a client central processing unit executing the client program, the grace period being different from the time slice. 13. The computer system of claim 12, wherein the grace period causes the time slice to terminate prematurely. 14. The computer system of claim 12, wherein, in addition to the time slice, the grace period also provides a time period for performing the first function. 15. The computer system of claim 10, wherein the first function comprises one of the following: A dispatchable unit that completes execution on a processor on which a second program is executed; or This allows the dispatchable unit to be reassigned on another processor in the computing environment. 16. A method for facilitating processing in a computing environment, the method comprising: The first program provides a second program with an indication that the warning tracking facility has been installed in the computing environment, and the warning tracking facility provides the second program with a grace period to perform the first function; The first procedure notifies the second procedure that the grace period has commenced; and After the grace period, the first procedure will perform the second function. The method further includes: receiving a warning tracking registration request from a second program by a first program and activating the second program to participate in the warning tracking facility. 17. The method of claim 16, wherein the first program is a host program and the second program is a client program, wherein the client program is able to access shared resources of the computing environment during a time slice provided to a client central processing unit executing the client program, the grace period being distinct from the time slice.