Auxiliary Processor Command Type Filtering

Abstract

The coprocessor command type filtering includes determining whether the target coprocessor is configured to support the selected command type filtering mode and whether another coprocessor is configured to support the selected command type filtering mode. Based on a determination that the target coprocessor is not configured to support the selected command type filtering mode and based on a determination that the other coprocessor is configured to support the selected command type filtering mode, the command is forwarded to the other coprocessor for processing to determine whether the command is valid for the selected command type filtering mode. Based on the processing at the other coprocessor, an indication of whether the command is valid for the selected command type filtering mode is obtained. Based on the indication that the command is valid for the selected command type filtering mode, the command is sent to the target coprocessor for execution.

Description

Technical Field

[0001] One or more aspects generally relate to facilitating processing within a computing environment, and more particularly to facilitating processing related to command processing within a computing environment.

Background Art

[0002] Computing environments often include different types of processors to enhance processing. As an example, a computing environment can include one or more central processing units regarded as main processors and one or more auxiliary processors regarded as being subordinate to the central processing unit. Auxiliary processors generally execute a particular type of task. For example, a particular example of an auxiliary processor is a crypto (cryptography) card used to perform encryption operations.

[0003] An example of a crypto card provided by International Business Machines Corporation of Armonk, New York, is the Channel Connect Crypto Express card. The Crypto Express card is defined to support a number of types of commands such as commands that use encryption keys (referred to as secure key commands), commands that use clear keys (referred to as clear key commands), hash commands, query commands, random number generator commands, and the like. Further, the Crypto Express card is designed to support a number of modes including, for example, the Common Cryptographic Architecture (CCA) mode, the Accelerator mode, and the Enterprise Public Key Cryptography Standard (PKCS) mode (alternatively, the XCP / EP11 - Enterprise PKCS #11 mode). Each mode is configured to process a particular type of command.

[0004] The Crypto Express card can be configured to operate in one of a number of different modes during the duration of the activated machine configuration. Therefore, if a customer wants to use different modes, the computing environment will include at least that number of cards for the different modes, each card being configured in a different mode and capable of processing a specific type of command defined for that mode.

SUMMARY OF THE INVENTION

[0005] By providing a computer program product to facilitate processing within a computing environment, the disadvantages of the prior art are overcome and additional advantages are provided. The computer program product includes one or more computer-readable storage media and program instructions collectively stored on the one or more computer-readable storage media for performing a method. The method includes determining whether a target auxiliary processor among a plurality of auxiliary processors in a computing environment is configured to support a selected command type filtering mode, and checking whether another auxiliary processor among the plurality of auxiliary processors is configured to support the selected command type filtering mode. Based on a determination that the target auxiliary processor is not configured to support the selected command type filtering mode and based on the fact that another auxiliary processor is configured to support the selected command type filtering mode, the command is transferred to the other auxiliary processor for processing to determine whether the command is valid for the selected command type filtering mode. Based on the processing at the other auxiliary processor, an indication of whether the command is valid for the selected command type filtering mode is obtained. The command is sent to the target auxiliary processor for execution based on obtaining an indication that the command is valid for the selected command type filtering mode.

[0006] By processing the command with another auxiliary processor, the execution of the command is simulated, and as a result, it can be determined whether the command is valid for execution on the target auxiliary processor. The simulation eliminates the need to maintain a static list of auxiliary processor commands for each supported auxiliary processor type and each command type filtering mode. In this way, the processing is facilitated and the performance is improved.

[0007] In one embodiment, the command is rejected as being invalid for the selected command type filtering mode based on obtaining an indication that the command is invalid for the selected command type filtering mode, and execution on the target auxiliary processor is withheld. In this way, by simulating the command with another auxiliary processor and determining that the command is invalid in the selected command type filtering mode and therefore cannot be executed on the target auxiliary processor upon request, the processing is facilitated and the performance is improved.

[0008] In one embodiment, rejecting includes placing the error code in a central location to facilitate access to the error code. By returning the error code using a central location that is independent of the auxiliary processor mode, it becomes easier for a program to search for the error code regardless of who generated the error (e.g., the hypervisor using command type filtering simulation, the auxiliary processor in a specific mode, etc.).

[0009] In one embodiment, a command is added to a command list as a selected command type filtering mode command based on obtaining an indication that the command is valid for the selected command type filtering mode. The command list can be used to determine which commands are valid for execution on a target auxiliary processor. Further, in one embodiment, a command is added to the command list as a valid auxiliary processor command based on obtaining an indication that the command is invalid for the selected command type filtering mode. The dynamically updated command list facilitates processing and improves performance by facilitating the determination of which commands are valid for a target processor. However, the command list is optional because the command can be simulated on one or more auxiliary processors that support the selected command type filtering mode.

[0010] In one embodiment, a command is rejected based on a determination that a plurality of auxiliary processors are not configured to support the selected command type filtering mode. In one embodiment, if none of the auxiliary processors support the selected command type filtering mode, the simulation is not executed, thereby facilitating processing and improving performance.

[0011] In one embodiment, based on the determination that the target auxiliary processor is not configured to support the selected command type filtering mode, and based on the fact that another auxiliary processor is configured to support the selected command type filtering mode, a determination is made as to whether a command is on the command list, and the command list can be used to determine whether a command can be executed by the target auxiliary processor. The command is transferred to another auxiliary processor for processing based on the determination that the command is not on the command list. The dynamically updated command list facilitates processing and improves performance by facilitating the determination of which commands are valid for the target auxiliary processor.

[0012] In one embodiment, a command is added to the command list as a valid selected command type filtering mode command based on the success of the execution of the command by another auxiliary processor. In one embodiment, a command is added to the command list as a valid auxiliary processor command based on the failure of the execution of the command by another auxiliary processor.

[0013] As an example, the selected command type filtering mode is a stateless command filtering mode. Further, as an example, the plurality of auxiliary processors include a plurality of cryptographic cards.

[0014] Computer-implemented methods and systems related to one or more aspects are further described and claimed herein. Further, services related to one or more aspects may be further described and claimed herein.

[0015] Additional features and advantages are realized by the techniques described herein. Other embodiments and aspects are described in detail herein and considered a part of the claimed aspects.

[0016] One or more aspects are specifically pointed out and distinctly claimed as examples in the claims at the conclusion of this specification. The foregoing, as well as the objects, features, and advantages of one or more aspects, will be apparent from the following detailed description taken in conjunction with the accompanying drawings.

Brief Description of the Drawings

[0017]

Figure 1A

Figure 1B

Figure 2A

Figure 2B

Figure 2C

Figure 2D

Figure 3A

Figure 3B

Figure 3C

Figure 3D

Figure 3E

Figure 4A

Figure 4B

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Figure 6C

Figure 6D

Figure 7A

Figure 7B

Figure 8

Figure 9

Best Mode for Carrying Out the Invention

[0018] In one or more aspects of the present invention, a filtering capability is provided such that an auxiliary processor, such as a cryptographic card, can dynamically determine for each command whether the command obtained by the auxiliary processor should be executed by the auxiliary processor. For example, a filtering indicator for each one or more commands (e.g., a selected command type filtering indicator) is used to determine whether the received command is a valid command type specified by the filtering indicator for each command, and thus whether it should be executed by the auxiliary processor. In one embodiment, the filtering indicator for each one or more commands is set based on a computing policy associated with the command originator for each command. Thus, a command issued by a certain originator may be a valid command type for execution as specified by the filtering indicator for each command set based on the originator's computing policy, while a command issued by another originator may be invalid.

[0019] In one or more aspects, at least one filtering function should be installed on the auxiliary processor for the auxiliary processor to be involved in per-command filtering. Various filtering functions may be installed, and each function has at least one associated filtering indicator (e.g., a selected command type filtering indicator) used in per-command filtering. One example of a filtering function is a stateless command filtering function where a selected command type (e.g., a stateless command type command) is valid for execution. For example, if the auxiliary processor supports, for example, a stateless command filtering function and the received command has a stateless command type filtering indicator set to a selected value, e.g., 1, the command may be a stateless command type command to be executed. If the command is of another command type, even if it is supported by the configured mode of the auxiliary processor (e.g., the common cipher architecture (CCA) mode, alias, coprocessor mode), the command is considered invalid. However, if the stateless command type filtering indicator within the command is set to another value, e.g., zero, the command can be any command type supported by the configured mode of the auxiliary processor that executes it. Thus, in one example, when a filtering function such as a stateless command filtering function is supported, an auxiliary processor configured in a mode herein referred to as the command set mode can be used to execute either the full set of command types supported in the configured mode (e.g., the coprocessor mode) or a reduced set of command types (e.g., only stateless command type commands).

[0020] Although a stateless command filtering function is described herein as one example, other filtering functions or techniques may be applied. For example, a master key filtering function where the selected command type is a master key management key command can be used. As another example, filtering can be implemented using use case restrictions imposed by a policy. For example, if the selected command access is priced differently from general cryptographic command access, a filter can be imposed on the purchased use case. A further level of filtering can be based on a performance service contract, and commands are ranked with high or low service response performance priorities based on the purchased performance. Other filtering functions or techniques can also be used. Each application of the filtering function is allowed without reconfiguring the auxiliary processor to another mode. The filtering functions may be used in conjunction with each other or separately from each other. Many examples are possible.

[0021] In one or more embodiments, a computing environment includes a plurality of auxiliary processors, and one or more of the auxiliary processors may not support a command type filtering function or a specific command type filtering function or both. Therefore, in one embodiment, based on the acquisition of a command request, a determination is made as to whether the target auxiliary processor indicated by the request supports the filtering function (also referred to as the command type filtering mode) indicated by the request. If the target auxiliary processor does not support the requested function but another auxiliary processor does, according to one aspect of the present invention, the operation of the command in the selected command type filtering mode is simulated by executing the command on another auxiliary processor. If the execution of the command on another auxiliary processor is valid, the command is executed on the target processor.

[0022] One embodiment of a computing environment incorporating and using one or more aspects of the present invention is described with reference to FIG. 1A. In one example, the computing environment 100 includes at least one central processing unit 102 and at least one auxiliary processor (AP) 104, each of which is coupled to at least a portion of a memory referred to as system memory 106. As one example, the system memory 106 includes a hardware system area that is indirectly accessible and not visible to programs executed by the central processing unit. (Indirectly accessible, as used herein, means that the hardware system area, or an auxiliary processor queue (described below) stored therein, is accessible only by certain limited instructions and otherwise is not accessible (e.g., cannot be loaded into it, the program does not know the address, etc.).) One or more auxiliary processor queues 108 are disposed within the system memory. These queues cannot be directly viewed from the user program and instead are considered part of the machine (i.e., the machine including the central processing unit, system memory, and auxiliary processor). The central processing unit has access rights to the queues within the system memory, for example, by issuing instructions to issue requests to the queues, remove responses from the queues, or both. However, the auxiliary processor has direct access rights to the queues, for example, via a transport layer 110 (e.g., i390CO), and is responsible for removing requests from the queues, processing the requests, and issuing responses to the requests to the queues.

[0023] Another embodiment of a computing environment incorporating one or more aspects of the present invention is described with reference to FIG. 1B. In this embodiment, the machine includes at least one host central processing unit 150 that includes virtual support and includes a plurality of guests 152 (e.g., guest operating systems or guest programs or both). The host central processing unit is coupled to at least a portion of a memory referred to as system memory 154. In addition, there is at least one auxiliary processor 156, which is also coupled to system memory 154, for example, via transport layer 160. As one example, system memory 154 includes a hardware system area, and one or more auxiliary processor queues 158 are disposed within the system memory.

[0024] As shown, without limitation, there are different types of auxiliary processors, including cryptographic cards or adapters. A specific example of a cryptographic card is the Crypto Express card offered by International Business Machines Corporation of Armonk, New York. Although an exemplary cryptographic card is provided, other cryptographic cards offered by International Business Machines Corporation or other companies or both can incorporate, or use, or both one or more aspects of the present invention. Further, other types of auxiliary processors can incorporate, or use, or both one or more aspects of the present invention.

[0025] In one embodiment, an auxiliary processor, such as a cryptographic card (e.g., Crypto Express card), supports a plurality of modes, including, without limitation, as examples, coprocessor mode, accelerator mode, and enterprise public key cryptography standard (PKCS) mode (e.g., XCP / EP11 - enterprise PKCS #11). Additional fewer or other or both modes may be supported in other examples. Each of the modes can have its own AP message structure and format.

[0026] As an example, an auxiliary processor message is composed of a number of data segments, and the data segments may not be adjacent to each other; instead, one or more of them may be interleaved. These data segments are referred to as scatter-gather data segments. In one example, the cryptographic card does not have direct access to the enqueued AP message, and a part of the message (e.g., the lower part of the AP message) contains data that can be used by the cryptographic card, for example, to execute an AP command. Therefore, the AP command transport layer (e.g., transport layers 110, 160) copies the relevant data from the AP command request message, packages it into a format (e.g., the command request message of the crypto card) that the cryptographic card understands, and sends it to the cryptographic card. Similarly, after the AP command is executed by the cryptographic card, the cryptographic card generates a cryptographic card command response message, for example, including packets 5 and 6, and sends it to the AP command transport layer, and the AP command transport layer repackages it into an AP command response message. For example, the transport layer uses various parts of the AP command request message and the cryptographic card's command response message to provide an AP command response message including a header, a sub-header, and packets. Then, the transport layer sends the AP command response message to the AP queue, where it is later dequeued by a program. Further details of the AP command request message and the AP command response message will be described below, including the aspects of the messages used according to the command type filtering of one or more aspects of the present invention.

[0027] According to one aspect of the present invention, an auxiliary processor (e.g., an encryption card) is designed such that a machine hypervisor can request command type filtering according to computing policies (e.g., licensing requirements such as customer license terms, high availability requirements, resource requirements or both, etc.). Since customers have different computing policies associated therewith (e.g., license terms, permissions, or resource requirements such as high availability requirements, or combinations thereof), not all types of commands are available to a particular customer. Thus, according to one aspect of the present invention, command type filtering is provided, such that a selected auxiliary processor (e.g., an encryption card configured for a particular mode (e.g., coprocessor mode)) can be used for different computing policies, and thus, customers with different permissions, without the need to reconfigure the auxiliary processor to different support modes.

[0028] As an example, in accordance with one or more aspects of the present invention, an AP command type filtering function (APFT) is provided that enables filtering of AP commands based on one or more selected AP command type filtering functions for each command. In one example, the one or more selected AP command type filtering functions include a stateless AP command filtering function (SAPCF). Aspects of the AP command type filtering function and the stateless AP command filtering function are described herein with respect to a particular architecture, such as the z / Architecture(R) hardware architecture provided by International Business Machines Corporation of Armonk, New York. One embodiment of the z / Architecture hardware architecture is described in "z / Architecture Principles of Operation", IBM Publication No. SA22-7832-12, 13th Edition, September 2019, which is hereby incorporated by reference in its entirety. IBM and Z / ARCHITECTURE are registered trademarks of International Business Machines Corporation in at least one jurisdiction. However, the z / Architecture hardware architecture is merely one exemplary architecture. Aspects of the present invention can be based on, but are not limited to, the Intel x86 architecture, other architectures of International Business Machines Corporation, or architectures of other companies, or other architectures including combinations thereof.

[0029] In one example, when the stateless AP command filtering function is installed, the AP command type filtering function is installed. Process assist processor queue instructions are used in accordance with aspects of the present invention to determine whether the stateless AP command filtering function is installed.

[0030] One example of a Process Auxiliary Processor Queue (PQAP) instruction is described with reference to FIG. 2A. As shown, in one example, the Process Auxiliary Processor Queue instruction 200 includes an instruction code (opcode) 202 (e.g., bits 0 to 15 of a 32-bit instruction) that indicates the process operation of the auxiliary processor queue. In one embodiment, the Process Auxiliary Processor Queue instruction utilizes a plurality of general-purpose registers including general-purpose registers 0, 1, and 2. The AP queue specified by the AP queue number (APQN) of general-purpose register 0 is processed according to the function code specified in general-purpose register 0. Examples of general-purpose registers 0, 1, and 2 are further described below.

[0031] Referring to FIG. 2B, in one embodiment, the general-purpose register 0 (GR0) 210 is a 64-bit register that includes, for example, a function code (FC) 212 (e.g., bits 32 to 39) for indicating a selected function to be executed, a test function indicator (T) 214 (e.g., bit 40) used to indicate whether a mask of the installed function is provided in general-purpose register 2, and an auxiliary processor queue number (APQN) 216 (e.g., bits 48 to 63) that identifies an auxiliary processor queue (e.g., AP queue 108 (FIG. 1A), AP queue 158 (FIG. 1B)) to be processed according to the function code.

[0032] Based on the issuance of the Process Auxiliary Processor Queue instruction, the function code 212 can include one of a plurality of allowable codes, an example of which is code 00 Test AP Queue (TAPQ).

[0033] According to one or more aspects of the present invention, when the computing environment is, for example, in z / Architecture architecture mode and the APFT function is installed, if the TAPQ function code is specified (for example, FC = 00 in GR0), bit 40 of the general-purpose register 0 is defined as the test function bit (T) 214 for the TAPQ function. When T is 1, bits 0 to 31 of the general-purpose register 2 are replaced with a mask of the installed AP function and other related information, and an example thereof is described below. When T is zero, for example, indicating that the APFT function is not installed, the result of the general-purpose register 2 is limited to, for example, bit positions 32 to 63, and bit positions 0 to 31 are ignored and not changed. In this case, the AT field and the QD field (described below) are valid, and other bit positions are stored as zero.

[0034] As shown in the figure, in addition to the general-purpose register 0, the general-purpose registers 1 and 2 are used by the process assist processor queue instructions, and each of them is further described herein.

[0035] Referring to Figure 2C, in one embodiment, the general-purpose register 1 (GR1) 220 is, for example, a 64-bit register including, for example, an auxiliary processor queue status word (APQSW) 222 (for example, bits 32 to 63). At the completion of the process assist processor queue instruction, unless otherwise specified for a particular function, the APQSW field includes the AP queue status word. The AP queue status word indicates, for example, the status of the AP queue at the completion of the instruction.

[0036] Further, referring to Figure 2D, in one embodiment, the general-purpose register 2 (GR2) 230 is, for example, a 64-bit register including a plurality of fields. As described herein, in one embodiment, when bits 0 to 31 are set, they include a mask of the installed AP function and other related information. Exemplary fields of GR2 according to one or more aspects of the present invention include, for example, the following.

[0037] Mode 232: When set, this field (e.g., bits 3 - 5) indicates a plurality of possible AP mode functions. For example, when D (e.g., bit 3) is 1, the specified AP provides a coprocessor mode function; when A (e.g., bit 4) is 1, the specified AP provides an accelerator mode function; and when X (e.g., bit 5) is 1, the specified AP provides an XCP mode function.

[0038] SL234: When this field (e.g., bit 7) is 1, the stateless AP command filtering function (SAPCF) of one or more aspects of the present invention is installed. The SAPCF function is, for example, a PCI-X (Peripheral Component Interconnect Extended) crypto device function, which is installed, for example, in z / Architecture architecture mode in one embodiment.

[0039] Classification 236: This field (e.g., bits 8 through 15) contains information regarding the functional capabilities of a specified auxiliary processor (AP). Each bit represents a specific functional capability related to the functions provided by the auxiliary processor, as indicated in the register's mode field (e.g., bits 3 - 5). If zero is stored, for example, in bits 8 through 15 of the classification field, full native card functionality is available on the specified AP. The classification field is not a PCI-X crypto device function and is not set by the system firmware. Rather, it is optionally set by the hypervisor to provide either full native card functionality or one or more subsets of full native card functionality to one or more of the guests, based on the guests' privileges. As an example, bit 8 indicates the full AP command set (FAPCS) function. When bit 8 is set to a value of 1 (e.g., 1), it indicates that full native card functionality is available on the specified auxiliary processor. When bit 8 is set (e.g., to 1), zero (in one example) is stored in bit 9. Bit 9 indicates, for example, the stateless AP command (SAPC) function. When bit 9 is set to a value of 1 (e.g., 1), it indicates that only the stateless function is available on the specified auxiliary processor. When bit 9 is set (e.g., to 1), zero (in one example) is stored in bit 8. Bits 10 through 15 are reserved in one example.

[0040] Other functions that may be supported by a computing environment, or information related to one or more functions, or both, may be indicated by one or more bits of a mask within, for example, bits 0 through 31.

[0041] Auxiliary processor type (AT) 238: This field (e.g., bit positions 32 through 39) contains exemplary valid AP type values in the range of 0 through 255 that indicate, for example, various auxiliary processor types.

[0042] Number of AP queue entries (QD) 240: The number of queue entries for each AP queue in the configuration. QD is, by way of example, a value in the range of, for example, 0 to 31, and represents the number of queue entries in the decimal range of, for example, 1 to 32.

[0043] In one example, the installed function information returned to general-purpose register 2 applies to all APs of the same AP type and (in the case of integrated APs (e.g., AP type 10 or higher)) the same configuration mode. The installed function information persists, in one example, until at least the next subsystem reset. Functions can be added simultaneously. The functions may or may not be removed simultaneously when the last AP of the AP type is deconfigured.

[0044] General-purpose register 2 is changed as defined when the TAPQ function is completed by, for example, status code 0 (normal completion), or status code 3, response code, for example, 02 to 05 (unexpected state, for example, in-progress AP queue reset, AP deconfiguration, AP checkpoint stop, AP busy). Otherwise, general-purpose register 2 is not changed.

[0045] Specific fields, field locations, field sizes, bits, and field or bit values are described in one embodiment of this specification for process assist processor queue instructions and related registers, but other fields, field locations, field sizes, bits, field or bit values, or combinations thereof may be used without departing from one or more aspects of the present invention. Each field or bit or both of general-purpose registers not described herein may be blank, may have a predefined value (e.g., zero), or may contain values that can be ignored in one embodiment, or a combination thereof. There are many possibilities.

[0046] According to one or more aspects, an auxiliary processor (e.g., a crypto card) has logic for recognizing attributes of different types of commands. These attributes, in one embodiment, when considered together, define sets and subsets of commands. Different types of commands are provided by a hypervisor in one embodiment. The hypervisor determines a set of command type tags, for example, based on a set of customers that can receive command requests. For example, the type of command that can be represented by a set of command type tags is based on, for example, the computing policy of the customers that can receive command requests (e.g., license terms, permissions, resource requirements such as high availability requirements, etc.).

[0047] In one example, commands are associated with a set of tags (e.g., policy or filtering tags) that represent the attributes of the commands, and commands having the same tags can be considered a group. The same command can appear in multiple command type sets based on the set of command type tags imposed by the hypervisor. For example, a command can have a stateless command type tag to indicate that the command is a valid stateless command type command, a master key command type tag to indicate that the command is a valid master key command type command, etc. There are various possibilities for command types, command type functions, and command type commands, and each command can have one or more command type tags associated with it.

[0048] Instructions for a set of command type tags are obtained (e.g., provided, received, retrieved, etc.) by an auxiliary processor. The auxiliary processor (e.g., auxiliary processor firmware) separates expected commands into different sets of commands based on a set of command type tags that can be requested by the hypervisor. For example, in one particular example, the auxiliary processor receives a set of command type tags that includes tags for secure key command type commands (e.g., used to invalidate secure key commands when requested by a caller) and tags for stateless command type commands. Therefore, the auxiliary processor considers commands that use an encryption key (e.g., secure key command type commands) as part of a set of secure key command type commands, and the rest of the commands are considered part of a set of stateless command type commands that use the command attributes of each command. In other embodiments where the hypervisor provides other tags for other filtering functions, other sets of commands with commands corresponding to the other tags are provided. Many types of command sets are possible.

[0049] Furthermore, in one embodiment, a command request is configured to include one or more filtering indicators, such as one or more command type filtering indicators used to perform per-command filtering according to one or more aspects of the present invention. Further details regarding the selected command type filtering indicators included in the command request are described with reference to FIGS. 3A - 3B.

[0050] Referring to FIG. 3A, in one example, an AP command request message 300 includes a header 302, a sub-header 304, and a plurality of packets 306-312. In one example, one or more of the packets (e.g., one or more of packets-1 308-310) are configured to provide a command, and one or more of the packets (e.g., packet-2 312) are configured to provide input data. One of the packets includes a request connection programming request block (CPRB) 308 that includes one or more filtering indicators related to command-type filtering according to one aspect of the present invention.

[0051] For example, as shown in FIG. 3B, the request CPRB 308 includes an AP command filter mask 320 that includes one or more command-type filtering indicators. One example of a command-type filtering indicator is a stateless command-type indicator 322. This indicator indicates whether the permitted command set is for stateless command-type commands (e.g., an indicator 322 such as a selected bit set to 1) or for a full command set (e.g., an indicator 322 set to 0). Other indicators, flags, bits, etc. may be included in the request CPRB 308 to indicate other types of commands that can be filtered. For example, another indicator can indicate filtering based on a master key. Many other examples are possible.

[0052] In response to the message, a response is provided, which in one example is in the form of an AP command response message, an example of which is shown in FIG. 3C. As shown, the AP command response message 330 includes, for example, a header 332, a sub-header 334, and a plurality of packets 336-340. One of the packets includes a response CPRB 336 that includes a response to the request and can indicate an error according to one aspect of the present invention.

[0053] For example, as shown in FIG. 3D, the response CPRB 336 includes an error indication 350. The error indication can include an error code (e.g., CPRB return_code / reason_code) for reporting that the command requested by the customer is not permitted by a defined set of command type tags (e.g., imposed by a hypervisor or another entity).

[0054] In one example, referring to FIG. 3E, the error code is converted to a selected AP response code (e.g., 8B invalid stateless command) and stored in the header 332 within the response code field 352. This provides a central location for the error code.

[0055] In one embodiment, after the AP command request message enters the in - process state, if the stateless AP command filtering function is installed and the AP command request message sets the stateless command type bit (e.g., stateless command type indicator 322) to 1 in the CPRB, or if the stateless AP command filtering function is not installed but the stateless AP command function is installed and the AP command request message does not specify a stateless AP command, the normal processing of the command request ends. As an example, a type - 86 command response message specifying a format - 1 sub - header is returned with a response code 8B.

[0056] In one aspect, the command request message targets a particular auxiliary processor, referred to herein as the target auxiliary processor. Thus, according to an aspect of the present invention, a determination is made as to whether the target auxiliary processor can execute the command. For example, if the command request includes a filtering indicator (e.g., a selected command type filtering indicator such as a stateless command type indicator 322) indicating that the requester is only permitted to execute commands of a particular filtering function or mode, a determination is made as to whether the target auxiliary processor supports command type filtering, particularly the particular filtering function indicated by the command. In one example, this is determined via a process auxiliary processor queue instruction or a similar type of instruction. If the target auxiliary processor does not support a particular command type filtering mode, according to one aspect of the present invention, the command is executed by another auxiliary processor that supports the particular command type filtering mode, the result is checked, and then, if the result indicates a valid command for the selected command type filtering mode, the command is simulated by executing the command on the target auxiliary processor.

[0057] Further details regarding command simulation are described with reference to FIGS. 4A - 4B. In the example of FIGS. 4A - 4B, the computing environment is a cloud environment; however, in other embodiments, the computing environment is a non - cloud environment. Aspects of the present invention are not limited to a particular computing environment. Further, in the example of FIGS. 4A - 4B, the auxiliary processor is an encryption card. However, filtering may be used by other auxiliary processors and the encryption card is only one example.

[0058] Referring to FIG. 4A, in one embodiment, a hypervisor (e.g., hypervisors 672 (FIG. 6C), 692 (FIG. 6D) described below) obtains (e.g., receives, is provided, retrieves, has access to, etc.) a guest request policy 402 (e.g., cloud request policy) based on an account configuration 404 (e.g., cloud account configuration) and determines the operating mode of the guest (step 400). The request policy 402 includes, for example, an indication for each requester (e.g., guest, caller, customer) to be processed for the requester based on the computing policy (e.g., license terms, resource requirements such as high availability requirements, or permissions, or a combination thereof) provided by the account configuration 404 for the allowed command types. Based on the request policy, the hypervisor sets at least one indication (e.g., at least one bit) in the classification 236 to indicate the capabilities of the guest for the configuration. For example, if the guest is permitted to access the full AP command set based on the request policy, bit 8 is set to 1 and bit 9 is set to zero. However, if the guest is only permitted to access a subset of selected commands such as stateless command type commands, bit 8 is set to zero and bit 9 is set to 1. Other bits will be used for other types of functions. The setting of the bits is applied to all of the auxiliary processors of the configuration that indicate the operating mode of the guest for the configuration. By way of example, the setting of the classification 236 is performed at the time of the guest's initial program load (IPL) based on receiving a request or at another time for one or more guests and is saved (e.g., classification for each guest) to reflect the operating mode of each guest. Other embodiments are possible.

[0059] In addition, as described herein, the hypervisor obtains (e.g., receives, is provided, retrieves, has access to, etc.) an initial auxiliary processor command list 408 used in the simulation process. As an example, as described below, the hypervisor dynamically generates an AP command list based on information obtained from an encryption card that supports a selected command type filtering function (e.g., a stateless AP command filtering function), and uses the command list, for example, when simulating the stateless AP command filtering operation of a target encryption card that does not support the selected command type filtering function. In one example, it initializes the AP command list with a default value such as all zeros (an empty list), or a list of known stateless AP commands (or commands of other functions) with stateless AP command indicators.

[0060] Furthermore, the hypervisor obtains (e.g., receives, is provided, retrieves, has access to, etc.) an AP command request message 406 (e.g., message 300) from the guest (STEP 405). As an example, the hypervisor intercepts an AP command from the guest, and then the AP command is queued to the target AP queue based on the guest program queuing the AP command to the target AP queue via an enqueue command such as the NQAP (enqueue auxiliary processor queue) command of the z / Architecture hardware architecture, or another enqueue command of another architecture.

[0061] The hypervisor determines whether the guest is authorized for a configured command set mode of the auxiliary processor (e.g., the full set of commands of the coprocessor) (query 410). As an example, the hypervisor checks classification 236, which is based on the request policy 402 (which is based on the guest's computing policy), to determine whether the guest has access rights to the full set of commands (e.g., coprocessor mode) or a reduced set of commands (e.g., stateless command filtering mode). If the guest is authorized for the configured command set mode, the hypervisor sends the AP command to the target auxiliary processor, and the AP command is executed at the target auxiliary processor (e.g., the crypto card), and the result is returned to the guest (step 412).

[0062] However, if the guest is not authorized for the configured command set mode but is instead authorized for a selected mode such as the stateless command filtering mode (query 410), then a further determination is made (query 414) as to whether there is a cryptographic card in the machine configuration that supports the selected command type filtering function, e.g., by the hypervisor. For example, a determination is made as to whether the stateless command filtering function is supported by any of the cryptographic cards. This can be determined, for example, by executing the process auxiliary processor queue instruction for each cryptographic card. If it is determined that there is no cryptographic card that supports the selected command type filtering function, the hypervisor rejects the AP command because the guest is not permitted to use any of the cryptographic cards (step 416).

[0063] Returning to query 414, however, if there is at least one cryptographic card that supports the selected command type filtering function, for example by the hypervisor, a further determination is made as to whether the target cryptographic card supports the selected command type filtering function (query 420). If the target cryptographic card supports the selected command type filtering function as indicated by the process assist processor queue instruction, the hypervisor sets the filtering indicator, such as the selected command type filtering indicator in the command request, to a selected value (e.g., 1) and sends the command to the target cryptographic card for processing (step 422). For example, the stateless command type indicator 322 in the request CPRB 308 is set to 1, and then the request is sent to the target cryptographic card for processing.

[0064] The target cryptographic card obtains the command request message (e.g., receives, is provided, retrieves, etc.) and determines whether the command is valid for the selected command type filtering mode (query 424). For example, is it a command part of the set of commands of the selected command type filtering function? If the command is part of the set of commands of the selected command type filtering function, the command is executed by the target cryptographic card and the result is placed in the command response message of the cryptographic card, which is sent, for example, to the AP transport layer (step 426). The transport layer converts the command response message received from the cryptographic card into an AP command response message (e.g., message 330), which is returned to the guest (step 428).

[0065] Returning to query 424, if the command is not a valid selected command type filtering command (e.g., not within the set of commands of the selected command type filtering function), the command is rejected by the target cryptographic card as an invalid selected command type filtering command, and such an indication is returned to the transport layer (step 430). For example, as an example, a selected error code (e.g., error code 350) is included in the response CPRB of the response message of the cryptographic card, and the response message is sent to the transport layer. The transport layer converts the response message received from the cryptographic card and provides an AP command response message 330 including the error code 350 in the response CPRB 336 and the response code 352 in the header 332. For example, the transport layer converts the selected error code in the CPRB to an AP response code (e.g., 8B) and places it in the AP response code field of the AP response message header (e.g., response code 352) to facilitate access to the response code (step 432). The response message is sent to the guest (step 428).

[0066] Returning to query 420, if the target cryptographic card does not support the selected command type filtering function (e.g., stateless command filtering function), according to one aspect of the present invention, the hypervisor simulates the selected command type filtering operation (e.g., stateless command filtering operation) as described below, and the result of the operation is returned to the guest (step 450). Further details of simulating the selected command type filtering operation are described with reference to FIG. 4B.

[0067] Referring to FIG. 4B, in one embodiment, the hypervisor checks an AP command list (e.g., AP command list 408) for the requested command (step 452). For example, the hypervisor checks the AP command list to determine whether the target AP command is included in the AP command list. If the requested command is not in the list (query 454), an appropriate filtering indicator (e.g., a selected command type filtering indicator such as the stateless command type indicator 322) is set to a selected value, e.g., 1 (step 456), and the command is sent to one of the cryptographic cards that support the selected command type filtering function.

[0068] The cryptographic card processes the command, and the hypervisor checks the result (step 458). If the result indicates a command valid for the selected command type filtering function (query 460), the hypervisor adds the AP command to the AP command list as the selected command type filtering command (e.g., as a stateless AP command type command) (step 462). Moreover, the AP command is executed on the target cryptographic card, and the result is returned to the guest (step 464).

[0069] When returning to query 460, if the result indicates a command that is invalid for the selected command type filtering function, e.g., via an error code, the hypervisor adds the command to the command list as a valid AP command (but not as a valid selected command type filtering command) (step 466), and the AP command is rejected (step 468). For example, the hypervisor constructs an invalid stateless AP command error response message with a new AP response code 8B in the AP response code field (e.g., response code 352) of the AP command response message header (e.g., header 332), rejects the AP command as an invalid selected command type filtering command, and returns the constructed AP response message to the guest that enqueued the AP command to indicate to the guest that the command is not a selected AP command type command.

[0070] When returning to query 454, if the AP command is in the AP command list, for example, a further determination is made by the hypervisor as to whether the command is valid for the selected command type filtering function (query 470). If the command is valid for the selected command type filtering function, the process continues to step 464, the AP command is sent by the hypervisor to the target cryptographic card, the command is executed on the target cryptographic card, and the result is returned to the guest. However, if the AP command is invalid for the selected command type filtering function, the AP command is rejected by the hypervisor as an invalid command for the selected command type filtering function as described above, and the result is returned to the guest (step 468).

[0071] In one embodiment, when a guest program dequeues an AP command response message (e.g., message 330) from the AP queue via a dequeue command such as, for example, a dequeue assist process queue (DQAP) command of the z / Architecture hardware architecture or a command of another architecture, it receives an AP command response message processed by the cryptographic card (either from hypervisor simulation or from the crypto card). The guest program examines the same error code, e.g., code 8B, in the AP response code (e.g., response code 352), regardless of whether the AP command was rejected by the hypervisor simulation or the cryptographic card. However, in one embodiment, if the cryptographic card processes the AP command and does not process the hypervisor simulation, the guest program will only examine the error code in the CPRB of the command response message. Therefore, the CPRB error code can be used to determine the source of the error by examining the AP command response message.

[0072] As described herein, in one embodiment, if a guest is permitted to execute only a subset of commands (e.g., stateless command type commands), but none of the cryptographic cards within the hypervisor configuration support the selected mode (e.g., stateless AP command filtering), the hypervisor does not simulate the stateless AP command filtering function itself and does not permit the guest to use the cryptographic card.

[0073] However, according to one aspect of the present invention, if a guest is operating in a selected command type filtering mode (e.g., stateless AP command filtering mode), but the selected command type filtering function is not installed on the target cryptographic card, the hypervisor checks whether an AP command is a command of the selected command type filtering function by simulating the command. This is, in one example, performed instead of maintaining a static list of selected commands supported for each cryptographic card type, which is quite burdensome and not easy to obtain in time for the machine startup test. It uses information from one of the other cryptographic cards that support the selected command type mode to simulate the command on a target cryptographic card that does not support the selected command type mode function. The AP command response message is constructed by the hypervisor and the result is sent to the guest.

[0074] If a guest is operating in a selected command type mode and the selected AP command type filtering function corresponding to the selected command type mode is installed on the target cryptographic card, the hypervisor sets a stateless command type indicator in the CPRB and sends the command to the target cryptographic card to execute.

[0075] In one embodiment, the cryptographic card receives a command request message from the hypervisor (e.g., AP command request message 300), determines whether the command is permitted to be executed based on a set of command - type - filtering indicators imposed by the hypervisor within the CPRB, and if the command is determined to be valid based on a set of command - type indicators imposed by the hypervisor, executes the command and places the result in a command response message. The command response message is sent, for example, to an AP command transport layer (e.g., transport layers 110, 160), and the AP command transport layer converts the command response message into an AP command response message 330. Further, it converts a filtering error code (if found) within the CPRB into a selected AP response code, e.g., 8B. The transport layer places the response code in an AP response code field (e.g., response code 352) within an AP command response message header (e.g., header 332) and sends the result to the guest.

[0076] According to one aspect of the present invention, in order for a crypto card to report that a guest has requested an AP command not permitted by a set of command - type filtering indicators imposed by a hypervisor, an error code (e.g., an invalid stateless AP command error code) is defined in an error reporting field within a response CPRB of an AP command response message. The crypto card reports an AP command - type filtering error code in the error reporting field within the response CPRB of the AP command response message. However, the crypto - card error code within the CPRB is located at a different offset in different modes (e.g., coprocessor mode, EP11 mode), and its message structure and format are different. Therefore, a central location is provided that returns an AP error code (e.g., an AP response code) that is independent of the auxiliary processor mode, so that both the hypervisor and the guest can easily search for the error code regardless of who generates the error. As a result, an invalid selection mode error code (e.g., AP response code 8B) is defined within an AP response code field (e.g., response code 352) of an AP command response message header to report a filtered non - stateless AP command error. The AP response code is a common error reporting field for AP messages because the common error reporting field makes it easy for the guest to search for the error code regardless of who (e.g., a hypervisor using command - type filtering simulation, a crypto card in coprocessor mode, a crypto card in XCP mode, or a crypto card in accelerator mode, etc.) generates the error. However, the crypto card does not have access rights to the AP response code field, and therefore does not store the AP response code in the AP response code within the AP command response message header. The crypto - card error code stored in the error reporting field within the response CPRB of the AP command response message is generally outside the scope of the AP architecture.Therefore, the transport layer is configured to search for a selected command type filtering mode error code in the error report field within the response CPRB of the AP command response message, convert the error code within the CPRB into a response code, for example, 8B, and place it in the AP response code.

[0077] The presence of an invalid selection mode command error code in the error report field within the response CPRB of the AP command response message is useful for debugging purposes to determine whether the AP response code was generated by the cryptographic card or the hypervisor simulation, since the hypervisor simulation does not store an invalid selection mode command error code in the error report field within the response CPRB of the AP command response message.

[0078] One or more aspects of the present invention are closely associated with computer technology and facilitate processing, including command processing, within a computing environment and improve its performance. Further details of one embodiment of an aspect related to facilitating processing within a computing environment are described with reference to FIGS. 5A - 5B.

[0079] Referring to FIG. 5A, in one embodiment, a determination is made (500) as to whether a target auxiliary processor among a plurality of auxiliary processors in a computing environment is configured to support a selected command type filtering mode, and a check is made (502) as to whether another auxiliary processor among the plurality of auxiliary processors is configured to support the selected command type filtering mode.

[0080] Based on the determination that the target auxiliary processor is not configured to support the selected command type filtering mode, and based on the fact that another auxiliary processor is configured to support the selected command type filtering mode, the command is transferred to another auxiliary processor (504) for processing to determine whether the command is valid for the selected command type filtering mode. Based on the processing in the other auxiliary processor, an indication of whether the command is valid for the selected command type filtering mode is obtained (506).

[0081] Based on the obtaining of an indication that the command is valid for the selected command type filtering mode, the command is sent to the target auxiliary processor for execution (508).

[0082] In one embodiment, based on the obtaining of an indication that the command is invalid for the selected command type filtering mode, the command is rejected as invalid for the selected command type filtering mode and refrained from being executed in the target auxiliary processor (510).

[0083] In addition, in one example, the error code is placed in a central location to facilitate access to the error code (512).

[0084] As an example, the selected command type filtering mode is a stateless command filtering mode (514), and the plurality of auxiliary processors includes a plurality of cryptographic cards (516).

[0085] Referring to FIG. 5B, in one embodiment, a command is added to a command list as a selected command type filtering mode command (518) based on obtaining an indication that the command is valid for a selected command type filtering mode. The command list can be used to determine which commands are valid for execution on a target auxiliary processor (520). Further, in one embodiment, a command is added to the command list as a valid auxiliary processor command (522) based on obtaining an indication that the command is invalid for a selected command type filtering mode.

[0086] In one embodiment, a command is rejected (524) based on a determination that a plurality of auxiliary processors are not configured to support a selected command type filtering mode.

[0087] Further, in one embodiment, based on a determination that a target auxiliary processor is not configured to support a selected command type filtering mode and based on a determination that another auxiliary processor is configured to support a selected command type filtering mode, a determination is made as to whether the command is on the command list, and the command list can be used to determine whether the command can be executed on the target auxiliary processor (526). Based on a determination that the command is not on the command list, the command is transferred to another auxiliary processor for processing (528).

[0088] In one embodiment, a command is added to the command list as a valid selected command type filtering mode command (530) based on the success of command execution on another auxiliary processor. Moreover, a command is added to the command list as a valid auxiliary processor command (532) based on the failure of command execution on another auxiliary processor.

[0089] Other variations and embodiments are possible.

[0090] The command - type filtering of one or more aspects of the present invention can be incorporated and used in many computing environments. One exemplary computing environment is described with reference to FIG. 6A. As an example, the computing environment is based on the z / Architecture(R) hardware architecture provided by International Business Machines Corporation of Armonk, New York. However, the z / Architecture hardware architecture is only one exemplary architecture. The computing environment can be based on other architectures including, but not limited to, the Intel x86 architecture, other architectures of International Business Machines Corporation, or architectures of other companies, or combinations thereof.

[0091] As shown in FIG. 6A, the computing environment 600 includes, for example, a computer system 602 shown in the form of a general - purpose computing device. The computer system 602 can include, but is not limited to, one or more processors or processing units 604 (e.g., a central processing unit (CPU)), a memory 606 (alternatively, for example, system memory, main memory, main storage, central storage, or storage), and one or more input / output (I / O) interfaces 608, which are coupled to each other via one or more buses or other connections or both 610.

[0092] Bus 610 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of various bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA), Micro Channel Architecture (MCA), Enhanced ISA (EISA), Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI).

[0093] Memory 606 can include a cache 612, such as a shared cache that can be coupled to local cache 614 of processor 604, for example. Further, memory 606 can include one or more programs or applications 616, at least one operating system 618, and one or more computer-readable program instructions 620. The computer-readable program instructions 620 can be configured to perform the functions of embodiments of aspects of the present invention.

[0094] In one embodiment, memory 606 (e.g., at least the hardware system area of memory 606) is coupled to one or more auxiliary processors 621 via one or more auxiliary processor buses 623 and, in one or more embodiments, via an AP transport layer.

[0095] Computer system 602 can communicate with one or more external devices 630, such as, for example, a user terminal, a tape drive, a pointing device, a display, and one or more data storage devices 634, via an I / O interface 608. The data storage device 634 can store one or more programs 636, one or more computer-readable program instructions 638, or data, or a combination thereof. The computer-readable program instructions can be configured to perform the functions of embodiments of aspects of the present invention.

[0096] Computer system 602 can also communicate with a network interface 632, for example via an I / O interface 608, whereby the computer system 602 can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, and communicate with other computing devices or systems.

[0097] Computer system 602 can include, be coupled to, or both, removable / non-removable and volatile / non-volatile computer system storage media. For example, it can include, be coupled to, or both, a non-removable non-volatile magnetic medium (commonly referred to as a "hard drive"), a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), or an optical disk drive for reading from and writing to a removable non-volatile optical disk such as a CD-ROM, DVD-ROM, or other optical media, or a combination thereof. It should be understood that other hardware components or software components or both can be used with computer system 602. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems, etc.

[0098] Computer system 602 can be operable in a number of other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, suitable for use with computer system 602 include, but are not limited to, personal computer (PC) systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

[0099] Another example of a computing environment incorporating and using one or more aspects of the present invention is described below with reference to FIG. 6B. As an example, the computing environment of FIG. 6B can be based on the z / Architecture(R) hardware architecture provided by International Business Machines Corporation. However, the z / Architecture hardware architecture is merely one exemplary architecture. Again, the computing environment can be based on other architectures including, but not limited to, the Intel x86 architecture, other architectures of International Business Machines Corporation, or architectures of other companies, or combinations thereof.

[0100] In one example, the computing environment 650 includes a Central Electronic Processor (CEC) 652. The CEC 652 includes, for example, one or more processors (alternatively, Central Processing Units (CPUs)) 656, and a memory 654 (alternatively, system memory, main memory, main storage, central storage, storage) coupled to an Input / Output (I / O) subsystem 658, among other components. Further, in one embodiment, the memory 654 (e.g., at least the hardware system area of the memory 654) is coupled to one or more auxiliary processors 657 via one or more auxiliary processor buses and, in one or more embodiments, via an AP transport layer.

[0101] The I / O subsystem 658 may be part of the Central Electronic Processor or separate therefrom. It directs the flow of information between the main storage 654 and an Input / Output Control Unit 660 and Input / Output (I / O) devices 662 coupled to the Central Electronic Processor.

[0102] A number of types of I / O devices can be used. One particular type is the data storage device 664. The data storage device 664 can store one or more programs 666, one or more computer-readable program instructions 668, or data, or a combination thereof, etc. The computer-readable program instructions can be configured to perform the functions of embodiments of aspects of the present invention.

[0103] The central electronic processing unit 652 can include, be coupled to, or both, removable / non-removable volatile / non-volatile computer system storage media. For example, it can include, be coupled to, or both, a non-removable non-volatile magnetic medium (commonly referred to as a "hard drive"), a magnetic disk drive for reading and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), or an optical disk drive for reading and writing to a removable non-volatile optical disk such as a CD-ROM, DVD-ROM, or other optical media, or a combination thereof. It should be understood that other hardware components or software components or both can be used with the central electronic processing unit 652. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems, etc.

[0104] Furthermore, the central electronic processing unit 652 may be operable in a number of other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, suitable for use by the central electronic processing unit 652 include, but are not limited to, personal computer (PC) systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, and the like.

[0105] In one or more embodiments, the central electronic processing unit 652 provides logical partitioning or virtualization support or both. In one embodiment, as shown in FIG. 6C, the memory 654 includes, for example, one or more logical partitions 670, a hypervisor 672 that manages the logical partitions, and processor firmware 674. One example of the hypervisor 672 is Processor Resource / System Manager (PR / SM) provided by International Business Machines Corporation of Armonk, New York. As used herein, firmware includes, for example, the microcode of the processor. It includes, for example, hardware-level instructions or data structures or both used in a higher-level machine code implementation. In one embodiment, it is generally sent out as microcode including, for example, reliable software, or microcode specific to the underlying hardware, and includes proprietary code that controls access to the operating system by the system hardware.

[0106] Each logical partition 670 can function as a separate system. That is, each logical partition can independently be reset and execute a guest operating system 676, such as the z / OS(R) operating system provided by International Business Machines Corporation of Armonk, New York, or other control code 678, such as coupling function control code (CFCC), and can operate with different programs 680. The operating system or application program operating in the logical partition may appear to have full and complete access to the system, but in fact only a part thereof is available. Although z / OS is provided as an example, other operating systems may be used in accordance with one or more aspects of the present invention.

[0107] Memory 654 is coupled to a CPU 656 (FIG. 6B), which is a physical processor resource that can be allocated to a logical partition. For example, logical partition 670 includes one or more logical processors, each of which represents all or an allocation of the physical processor resources 656 that can be dynamically allocated to the logical partition.

[0108] Furthermore, in a further embodiment, the central processing unit provides virtual machine support (regardless of the presence or absence of logical partitioning support). As shown in FIG. 6D, the memory 654 of the central processing unit 652 includes, for example, one or more virtual machines 690, a virtual machine manager such as a hypervisor 692 for managing the virtual machines, and processor firmware 694. One example of the hypervisor 692 is the z / VM(R) hypervisor provided by International Business Machines Corporation of Armonk, New York. The hypervisor is sometimes referred to as a host. z / OS and z / VM are trademarks or registered trademarks of International Business Machines Corporation in at least one jurisdiction.

[0109] CPC's virtual machine support provides the ability to run multiple virtual machines 690, each operating with a different program 696 and capable of executing a guest operating system 698 such as the Linux(R) operating system. Each virtual machine 690 can function as a separate system. That is, each virtual machine can be reset, run a guest operating system, and operate with a different program independently. Although the operating system or application program running on the virtual machine may appear to have full and complete access to the system, in fact only a portion thereof is available. z / VM and Linux are provided as examples, but other virtual machine managers and operating systems may be used in accordance with one or more aspects of the present invention. The registered trademark Linux(R) is used under sublicense from the Linux Foundation, an exclusive licensee of Linus Torvalds, owner of the trademark worldwide.

[0110] Another embodiment of a computing environment incorporating one or more aspects of the present invention is described with reference to FIG. 7A. In this example, computing environment 10 includes, for example, a native central processing unit (CPU) 12, a memory 14, and one or more input / output devices or interfaces 16 or both, coupled to each other via, for example, one or more buses 18 or other connections or both. By way of example, computing environment 10 can include a PowerPC(R) processor provided by International Business Machines Corporation of Armonk, N.Y., an HP Superdome with an Intel Itanium II processor provided by Hewlett-Packard Company of Palo Alto, Calif., or other machines based on architectures provided by International Business Machines Corporation, Hewlett-Packard, Intel Corporation, Oracle, etc., or combinations thereof. PowerPC is a trademark or registered trademark of International Business Machines Corporation in at least one jurisdiction. Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

[0111] The native central processing unit 12 includes one or more native registers 20, such as, for example, one or more general-purpose registers or one or more dedicated registers or both used during processing within the environment. These registers contain information representing the state of the environment at any given point in time.

[0112] In addition, the native central processing unit 12 executes the instructions and code stored in the memory 14. In one particular example, the central processing unit executes emulator code 22 stored in the memory 14. This code enables a computing environment configured with one architecture to emulate another architecture. For example, the emulator code 22 enables a machine based on an architecture other than the z / Architecture hardware architecture, such as a PowerPC processor, an HP Superdome server, etc., to emulate the z / Architecture hardware architecture and execute software and instructions developed based on the z / Architecture hardware architecture.

[0113] Further details regarding the emulator code 22 are described with reference to FIG. 7B. The guest instructions 30 stored in the memory 14 include software instructions (e.g., related to machine instructions) developed to be executed on an architecture other than the architecture of the native CPU 12. For example, the guest instructions 30 may be designed to execute on a processor based on the z / Architecture hardware architecture, but instead are emulated by the native CPU 12 which may be, for example, an Intel Itanium II processor. In one example, the emulator code 22 fetches one or more guest instructions 30 from the memory 14 and optionally includes an instruction fetching routine 32 for providing local buffering to the fetched instructions. It further includes an instruction conversion routine 34 for determining the type of the fetched guest instructions and converting the guest instructions into one or more corresponding native instructions 36. This conversion includes, for example, identifying the function to be performed by the guest instructions and selecting the native instructions for performing that function.

[0114] Furthermore, the emulator code 22 includes an emulation control routine 40 for executing native instructions. The emulation control routine 40 causes the native CPU 12 to execute a routine of native instructions that emulate one or more previously fetched guest instructions, and at the end of such execution, can return control to the instruction fetch routine to emulate the fetching of the next guest instruction or group of guest instructions. The execution of the native instruction 36 can include loading data from the memory 14 into a register, storing the data back from the register into the memory, or performing a certain type of arithmetic or logical operation determined by a conversion routine.

[0115] Each routine is implemented, for example, in software, which is stored in the memory and executed by the native central processing unit 12. In other examples, one or more of the routines or operations are implemented in firmware, hardware, software, or a combination thereof. The registers of the emulated processor can be emulated using the registers 20 of the native CPU or by using locations within the memory 14. In an embodiment, the guest instruction 30, the native instruction 36, and the emulator code 22 may reside in the same memory or may be distributed among different memory devices.

[0116] Furthermore, in one embodiment, the computing environment 10 includes one or more auxiliary processors 15 coupled to the memory 14. The one or more auxiliary processors are defined by an architecture and configured to emulate another architecture. For example, the auxiliary processor fetches guest commands of the emulated architecture, converts the guest commands into native commands of one architecture, and executes the native commands.

[0117] The computing environments described above are merely examples of computing environments that can be used. Without limitation, other environments including, but not limited to, an unpartitioned environment, a partitioned environment, a cloud environment, or an emulated environment, or combinations thereof may be used, and the embodiments are not limited to any one environment. Although various examples of computing environments are described herein, one or more aspects of the present invention can be used in many types of environments. The computing environments provided herein are merely examples.

[0118] Each computing environment can be configured to include one or more aspects of the present invention. For example, each can be configured in accordance with one or more aspects of the present invention for each command - type filtering.

[0119] As described herein, in one or more aspects, command - type filtering for each command is provided. Many filtering techniques can be used. In one particular example, stateless command filtering is provided. Using this filtering, in one example, if the stateless command filtering function is set, for example, to zero, the stateless command filtering function is not installed, and an auxiliary processor (e.g., a crypto - card) enables commands supported by the auxiliary processor to be executed. Otherwise, the stateless command filtering function is installed, and whether a command is executed by the auxiliary processor depends on the value of a set of command - type filtering indicators imposed by a hypervisor within the command request. An exemplary embodiment including a stateless command - type indicator within a command request message is described below.

[0120] When the stateless command type indicator (e.g., indicator 322) is set to zero in the command request message (e.g., message 300), the crypto card enables all commands supported by the crypto card to be executed. When the stateless command type indicator (e.g., indicator 322) is set to one in the command request message (e.g., message 300), the crypto card does not permit all commands supported by the crypto card to be executed. If the command in the command request message is a stateless command type command, the command is executed. If the command in the command request message is not a stateless command type command, the command is rejected by an error code in the CPRB (e.g., response CPRB 336) of the command response message (e.g., message 330).

[0121] In one or more aspects, either stateless command filtering (also referred to as non-secure key filtering mode, e.g., only stateless command type commands are processed) using a configured mode of the crypto card (e.g., coprocessor mode), or another filtering mode with a reduced set of commands without configuring the crypto card in a new crypto card mode such as, for example, an accelerator mode may be provided. Filtering techniques may be used to filter a set of commands such as stateless command type commands, or other command type commands in other examples such as master key management commands. This reduces the number of auxiliary processors to be purchased and managed.

[0122] Furthermore, one or more aspects of the present invention provide the ability to dynamically switch the command-type filtering mode for each command, and the command-type filtering is performed for each command. Therefore, each command may be valid or invalid during command processing based on a command-type flag value (e.g., a command-type filtering indicator). The program does not need to switch between different cryptographic card modes to execute different sets of filtering commands. Therefore, the complexity of managing and using the number of cryptographic cards remains the same regardless of the number of supported filtering modes. By reducing the complexity of the program, more efficient code is added, and the code execution time and performance are improved.

[0123] In a further aspect, information from an auxiliary processor (e.g., a new version) that supports a selected command-type filtering function is used to simulate a filtering function not supported by a target auxiliary processor (e.g., an old version).

[0124] In one or more aspects, the hypervisor determines an AP command type filtering mode, an AP command type set, and a set of AP command type flags based on guest needs (e.g., a set of cloud environment customers). The hypervisor sets the AP command set mode based on the set of AP commands permitted by the cloud environment guest, intercepts the AP commands issued by the guest, and executes that mode of operation by performing appropriate actions. The hypervisor provides AP command set filtering mode support to cloud environment customers by using the corresponding hardware AP command set filtering mode functionality of the crypto card configured in the guest configuration. If the guest is permitted to execute only, for example, a stateless subset of AP commands, but none of the crypto cards in the hypervisor configuration support the stateless AP command type filtering (hardware) functionality, the guest is not permitted to use the crypto card. However, if at least one crypto card supports stateless command filtering, the hypervisor, for example, if the guest is operating in stateless AP command mode but the stateless AP command type filtering (hardware) functionality is not installed on the target crypto card, simulates the stateless AP command type filtering operation itself.

[0125] Hypervisor simulation guarantees a functionally equivalent hardware filtering operation, for example, by simulating a stateless AP command type filtering operation on a target cryptographic card that does not support the stateless AP command type filtering (hardware) function using information from one of the cryptographic cards that support the stateless AP command type filtering (hardware) function (or other filtering functions). In one embodiment, the AP command transport layer (e.g., i390CO) is enhanced to provide a way to perform a uniform failure response regardless of the source of the error and to match the software implementation within the hypervisor to the cryptographic card.

[0126] In one or more aspects, the same crypto card mode (e.g., coprocessor or EP11 mode) can be used to provide a full AP command set mode, a stateless AP command mode, or another filtering mode with a reduced set of commands, without configuring the crypto card in another crypto card mode such as an accelerator mode. The customer does not need to purchase additional cards for the crypto card filtering mode. The hypervisor can contribute to different guests with different AP command type filtering requirements, for example, by specializing different crypto domains of the same crypto card mode to different guests with different AP command type filtering requirements. The hypervisor can use a combination of software simulation and hardware filtering capabilities to support guests and change a non-crypto card type configuration to a symmetric crypto card type configuration. Using a combination of hardware and software filtering using a common interface is useful for a number of crypto card type configurations where one or more crypto card types do not provide any hardware filtering functions or do not necessarily provide all supported hardware filtering functions (e.g., asymmetric crypto card types).

[0127] In one aspect, the hypervisor need not maintain a static list of AP commands for each filtering mode for each crypto card type it supports for simulation. Maintaining an up-to-date static list of AP commands for each filtering mode for each crypto card type and mode the hypervisor supports is a burden and not easy to obtain in time for the machine startup test. As a result, the hypervisor cannot guarantee that software AP command type filtering is functionally equivalent to hardware AP command type filtering by maintaining a static list of AP commands for each filtering mode for each crypto card type it supports.

[0128] In one aspect, the program need not switch between different crypto card modes to execute different filtering command sets. Therefore, the complexity of crypto card management and use remains the same regardless of the number of supported filtering modes. This reduction in program complexity further allows for more efficient code to be added, improving code execution time and performance. Further, in one aspect, the hypervisor need not check the proper setting of the command type flags in the CPRB provided by the guest program. Instead of the guest program that generates the AP command request message, it inserts the command type flags into the CPRB of the AP command request message based on the set of AP commands permitted by the guest. As a result, the hypervisor need not set (or reset) the command type flags in the CPRB or reject the command if the command setting violates the command type filtering settings permitted by the guest.

[0129] In one aspect of using both hardware filtering technology and software filtering technology, using a common interface can be useful for a number of crypto - card types where one or more crypto - card types do not provide any hardware filtering functionality or do not necessarily provide all supported hardware filtering functions (e.g., asymmetric crypto - card types). For example, in a hypervisor configuration consisting of a single machine with multiple crypto - card types, where not all crypto - card types support a selected command - type filtering function, e.g., a stateless command filtering function, the hypervisor can simulate the selected command - type filtering function itself for those crypto - card types that do not support it, to provide the same selected command - type filtering function across all available crypto - cards. Similarly, in a hypervisor configuration consisting of multiple machines with different models where guests can be relocated to any of those machine models, and not all models support, e.g., a selected command - type filtering function, the hypervisor can simulate a stateless command filtering function itself for those machine models that do not support it, to provide the same selected command - type filtering function across all available machine models. Thereby, the hypervisor can use a combination of software and hardware capabilities to transform an asymmetric crypto - card type configuration into a symmetric crypto - card type configuration and provide command - type filtering function support to guests. This technique can also be used to support a number of hardware filtering functions. Other variations are possible.

[0130] Furthermore, the hardware filtering function provides the ability to dynamically switch the filtering mode for each command, for example, and command type filtering is performed for each command. As a result, each command may be valid or invalid during command processing based on the command type flag value. Therefore, with this technique, the hypervisor can share the same crypto domain with a number of guests having different AP command type filtering requirements. Further, the program does not need to switch between various crypto card modes to execute different filtering command sets. Therefore, the complexity of managing and using the number of crypto cards remains the same regardless of the number of supported filtering modes. This reduction in program complexity further allows for more efficient code to be added, improving code execution time and performance.

[0131] In one or more embodiments, the hypervisor can be a host such as a logical partition hypervisor, an operating system such as z / VM(R), or a device driver. z / VM can contribute to a number of guests with different policies using the same crypto card. The crypto device driver may be used in place of the operating system in a specific environment such as a Linux environment to retrieve the processed AP messages. The crypto device driver can contribute to a number of users, such as Docker containers or different applications with different policies. Either a manager such as a z / VM manager or the crypto device driver can switch from one filtering mode, such as a certain command type filtering mode, to another filtering mode for each command. In one example, when at least one guest executes only a single crypto command, the manager or the crypto device driver switches to the next guest, and the next guest executes crypto commands from a different filtering mode.

[0132] Although various embodiments are described herein, many variations and other embodiments are possible without departing from the aspects of the invention. It should be noted that each aspect or feature described herein, and its variations, can be combined with any other aspect or feature, provided there is no particular contradiction.

[0133] One or more aspects can be related to cloud computing.

[0134] This disclosure includes a detailed description of cloud computing, but it should be understood that the implementation of the teachings detailed herein is not limited to a cloud computing environment. Rather, embodiments of the invention can be implemented with any other type of computing environment, whether currently known or later developed.

[0135] Cloud computing is a service delivery model that enables convenient on-demand network access to a shared pool of configurable computing resources (such as networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0136] The characteristics are as follows.

[0137] On-demand self-service: Cloud consumers can automatically and unilaterally provision computing capabilities such as server time and network storage as needed, without the need for human interaction with a service provider.

[0138] Extensive network access: The functionality is available over the network and is accessed via standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0139] Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, and different physical and virtual resources are dynamically assigned and re-assigned in response to requests. Consumers generally have no control or knowledge of the exact location of the resources provided, but have a sense of location independence in that they may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0140] Rapid elasticity: The functionality can be provisioned quickly and elastically, and in some cases automatically, to scale out rapidly and be released quickly to scale in. For consumers, the functionality available for provisioning often appears to be unlimited and can be purchased in any quantity at any time.

[0141] Metered service: The cloud system automatically controls and optimizes resource use by leveraging measurement capabilities at an abstraction level appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). It can monitor, control, and report resource usage to provide transparency to both the provider and consumer of the services utilized.

[0142] The service model is as follows.

[0143] Software as a Service (SaaS): The function provided to consumers is to use the provider's application running on the cloud infrastructure. The application is accessible from various client devices through a thin-client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, server, operating system, storage, or even individual application functions, except for limited possibilities of user-specific application configuration settings.

[0144] Platform as a Service (PaaS): The function provided to consumers is to deploy consumer-created or acquired applications created using programming languages and tools supported by the provider onto the cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including the network, server, operating system, or storage, but control the deployed applications and, in some cases, the application hosting environment configuration.

[0145] Infrastructure as a Service (IaaS): The function provided to consumers is to provision processing, storage, network, and other basic computing resources, and consumers can deploy and run any software that can include an operating system and applications. Consumers do not manage or control the underlying cloud infrastructure, but control the operating system, storage, deployed applications, and, in some cases, have limited control over selected networking components (e.g., host firewall).

[0146] The deployment model is as follows.

[0147] Private Cloud: The cloud infrastructure is operated solely for an organization. The cloud infrastructure may be managed by the organization or a third party and may exist on-premises or off-premises.

[0148] Community Cloud: The cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., missions, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by the organization or a third party and may exist on-premises or off-premises.

[0149] Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0150] Hybrid Cloud: The cloud infrastructure is a composition of two or more clouds (private, community, or public), which remain distinct entities but are joined by standard or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0151] The cloud computing environment is service-oriented, emphasizing statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0152] Next, referring to FIG. 8, an exemplary cloud computing environment 50 is shown. As illustrated, cloud computing environment 50 includes one or more cloud computing nodes 52 that can communicate with local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, or an automotive computer system 54N, or combinations thereof. Nodes 52 can communicate with one another. Nodes 52 may be physically or virtually grouped in one or more networks such as the private, community, public, or hybrid clouds described above, or combinations thereof (not shown). Thereby, cloud computing environment 50 can provide infrastructure, platform, software, or combinations thereof as services such that cloud consumers need not maintain resources on local computing devices. It is intended that the types of computing devices 54A - 54N shown in FIG. 8 are merely exemplary, and that computing nodes 52 and cloud computing environment 50 can communicate with any type of computerized device via any type of network or network addressable connection or both (e.g., using a web browser).

[0153] Next, referring to FIG. 9, a set of functional abstractions provided by cloud computing environment 50 (FIG. 8) is shown. It should be understood in advance that the components, layers, and functions shown in FIG. 9 are merely exemplary and that embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided.

[0154] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based server 62, server 63, blade server 64, storage device 65, and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0155] The virtualization layer 70 provides an abstraction layer that can include the following examples of virtual entities: virtual server 71, virtual storage 72, virtual network 73 including a virtual private network, virtual applications and operating systems 74, and virtual clients 75.

[0156] In one example, the management layer 80 can provide the following functions. Resource provisioning 81 performs dynamic procurement of computing resources and other resources used to execute tasks within a cloud computing environment. Metering and pricing 82 performs cost tracking when resources are utilized within a cloud computing environment and creates and sends invoices or bills for the consumption of these resources. In one example, these resources can include application software licenses. Security performs identity verification of cloud consumers and tasks, and protects data and other resources. User portal 83 provides access rights to the cloud computing environment to consumers and system administrators. Service level management 84 performs cloud computing resource allocation and management so that the required service levels are met. Service quality assurance contract (SLA) planning and fulfillment 85 performs advance preparation and procurement of cloud computing resources for which future requirements are expected according to the SLA.

[0157] The workload layer 90 provides examples of functions that can utilize a cloud computing environment. Examples of workloads and functions that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom education delivery 93, data analysis processing 94, transaction processing 95, and command type filtering processing 96.

[0158] Aspects of the present invention can be a system, method, or computer program product, or a combination thereof, at any possible technical detail integration level. The computer program product can include one computer-readable storage medium (or multiple media) having computer-readable program instructions for causing a processor to execute aspects of the present invention.

[0159] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction-executing device. The computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following, namely, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or raised structures in grooves in which instructions are recorded, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed to be a signal per se that is transient, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire.

[0160] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface of each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each respective computing / processing device.

[0161] The computer-readable program instructions for carrying out the operations of the present invention may be written in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of object-oriented programming languages such as Smalltalk, C++, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to customize the electronic circuit for exclusive use to implement aspects of the present invention.

[0162] 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 invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0163] These computer-readable program instructions create means for causing the functions / operations specified in one or more blocks of a flowchart and / or block diagram to be performed, via the processor of a computer or other programmable data processing apparatus, such that the instructions, when executed via the processor of the computer or other programmable data processing apparatus, can create a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, or other devices, or combinations thereof, to function in a particular manner, such that the computer-readable storage medium containing the instructions constitutes a product including instructions for implementing the functions / operations specified in one or more blocks of a flowchart and / or block diagram.

[0164] The computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other devices such that the instructions, when executed on the computer, other programmable data processing apparatus, or other devices, cause the functions / operations specified in one or more blocks of a flowchart and / or block diagram to be performed, thereby creating a computer-implemented process.

[0165] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible embodiments of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram can represent a module, segment, or portion of instructions that include one or more executable instructions for implementing the specified logical function. In some alternative embodiments, the functions noted in the blocks may be performed out of the order noted in the figures. For example, two blocks shown in succession may in fact be accomplished as one step that is executed concurrently, substantially concurrently, partially or wholly in time overlap, or the blocks may sometimes be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams or flowcharts, or both, and combinations of blocks of the block diagrams or flowcharts, or both, can be implemented in a dedicated hardware-based system that performs the specified functions or operations or a combination of dedicated hardware instructions and computer instructions.

[0166] In addition to the above, one or more aspects may be provided, served, deployed, managed, serviced, etc. by a service provider that offers management of a customer environment. For example, the service provider can create, maintain, support, etc. computer code or computer infrastructure or both for one or more customers to execute one or more aspects. In return, the service provider can receive payment from the customer, for example, under a subscription or fee contract or both. Additionally or alternatively, the service provider can receive payment from the sale of advertising content to one or more third parties.

[0167] In one aspect, an application can be deployed to execute one or more embodiments. As one example, deploying the application includes providing a computer infrastructure operable to execute one or more embodiments.

[0168] As a further aspect, a computing infrastructure can be deployed that includes integrating computer-readable code into a computing system, and the code combined with the computing system can execute one or more embodiments.

[0169] Further, as a further aspect, a process can be provided for integrating a computing infrastructure that includes integrating computer-readable code into a computer system. The computer system includes a computer-readable medium, and the computer medium includes one or more embodiments. The code combined with the computer system can execute one or more embodiments.

[0170] Although various embodiments have been described above, these are merely examples. For example, computer environments of other architectures can be used to incorporate and use one or more embodiments. Further, different instructions, commands, or operations may be used. Additionally, different types of directives or tags, as well as different types of filtering modes or auxiliary processors or both may be specified. Many variations are possible.

[0171] Various aspects are described herein. Further, many variations are possible without departing from the aspects of the invention. Note that each aspect or feature described herein, and its variations, can be combined with any other aspect or feature, provided there is no conflict.

[0172] Furthermore, other types of computer environments can be utilized and are beneficial. As an example, a data processing system suitable for storing or executing or both of an executable program code can be used, which includes at least two processors directly or indirectly coupled to a memory element via a system bus. The memory elements include, for example, local memory utilized during actual execution of the program code, bulk storage, and cache memory that provides temporary storage of at least some program code to reduce the number of times the code has to be retrieved from the bulk storage during execution.

[0173] Input / output or I / O devices (including, but not limited to, keyboards, displays, pointing devices, DASD, tapes, CDs, DVDs, thumb drives, and other memory media, etc.) can be coupled to the system directly or via an intervening I / O controller. A network adapter may also be coupled to the system that enables the data processing system to be coupled to other data processing systems, remote printers, or storage devices via an intervening private or public network. Modems, cable modems, and Ethernet cards are just a part of the available types of network adapters.

[0174] The terms used in this specification are for the purpose of describing particular embodiments only and are not intended to be limiting. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises", "comprising", or both, when used in this specification, specify the presence of the stated feature, integer, step, operation, element, or component, or a combination thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or a combination thereof.

[0175] It is intended that all means or step-plus-function elements in the following claims, corresponding structures, materials, acts, and equivalents, if any, include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of one or more embodiments has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the forms disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. Embodiments were chosen and described in order to best explain the various aspects and practical applications, and to enable others of ordinary skill in the art to understand the various embodiments with various modifications as are suited to the particular use contemplated.

Claims

1. determining whether a target auxiliary processor among a plurality of auxiliary processors in a computing environment is configured to support a selected command type filtering mode; checking whether another auxiliary processor among the plurality of auxiliary processors is configured to support the selected command type filtering mode; transferring a command to the another auxiliary processor for processing to determine whether the command is valid for the selected command type filtering mode, based on a determination that the target auxiliary processor is not configured to support the selected command type filtering mode and based on a determination that the another auxiliary processor is configured to support the selected command type filtering mode; obtaining an indication of whether the command is valid for the selected command type filtering mode, based on processing at the another auxiliary processor; sending the command to the target auxiliary processor for execution, based on obtaining an indication that the command is valid for the selected command type filtering mode A method comprising the above steps.

2. The method of claim 1 further comprising, based on obtaining an indication that the command is not valid for the selected command type filtering mode, rejecting the command as not valid for the selected command type filtering mode and refraining from executing the command at the target auxiliary processor.

3. The method of claim 2, wherein rejecting the command further comprises placing an error code in a central location to facilitate access to the error code.

4. The method further comprises Based on obtaining an indication that the command is valid for the selected command type filtering mode, adding the command to a command list as a selected command type filtering mode command, where the command list can be used to determine which commands are valid for execution on the target auxiliary processor, and adding; Based on obtaining an indication that the command is invalid for the selected command type filtering mode, adding the command to the command list as a valid auxiliary processor command; The method according to claim 1, further comprising.

5. The method according to claim 1, further comprising rejecting the command based on a determination that the plurality of auxiliary processors are not configured to support the selected command type filtering mode.

6. The method is Based on a determination that the target auxiliary processor is not configured to support the selected command type filtering mode, and based on a determination that the other auxiliary processor is configured to support the selected command type filtering mode, determining whether the command is in the command list, where the command list can be used to determine whether the command can be executed on the target auxiliary processor, and determining; Based on a determination that the command is not in the command list, transferring the command to the other auxiliary processor for processing; The method according to claim 1, further comprising.

7. The method according to claim 6, further comprising adding the command to the command list as a valid selected command type filtering mode command based on the success of the execution of the command on the other auxiliary processor.

8. The method according to claim 6, further comprising adding the command to the command list as a valid auxiliary processor command based on the failure of the execution of the command on the other auxiliary processor.

9. The method according to claim 1, wherein the selected command type filtering mode is a stateless command filtering mode.

10. The method according to claim 1, wherein the plurality of auxiliary processors include a plurality of cryptographic cards.

11. A computer system for facilitating processing within a computing environment, the computer system comprising a memory, a processor communicating with the memory, the computer system being configured to execute a method, the method comprising determining whether a target auxiliary processor among a plurality of auxiliary processors in the computing environment is configured to support a selected command type filtering mode; checking whether another auxiliary processor among the plurality of auxiliary processors is configured to support the selected command type filtering mode; transferring a command to the another auxiliary processor for processing to determine whether the command is valid for the selected command type filtering mode, based on a determination that the target auxiliary processor is not configured to support the selected command type filtering mode and based on a determination that the another auxiliary processor is configured to support the selected command type filtering mode; obtaining an indication of whether the command is valid for the selected command type filtering mode, based on processing by the another auxiliary processor; sending the command to the target auxiliary processor for execution, based on obtaining an indication that the command is valid for the selected command type filtering mode A computer system including the above.

12. A program for causing a computer system to execute the method according to claims 1 to 10.

Images