HK1180803B - Method and system for controlling access to adapters of a computing environment - Google Patents

Description

Method and system for controlling access to adapters in a computing environment

Technical Field

The present invention relates generally to input/output (I/O) processing, and more particularly to controlling access to an input/output adapter of a computing environment.

Background

Many system architectures that use input/output adapters control access to these adapters by using a Central Processing Unit (CPU) based address translation mechanism. In such systems, memory mapped input/output (MMIO) is used, and based on the way memory is built, the hardware knows whether the instructions executed by the processor are directed to actual memory or whether it is actually directed to the memory of one of the adapters. The hardware is then able to manipulate it accordingly.

However, some systems may not use traditional memory mapped I/O.

United states patent No. 7,617,340 entitled "I/oadapter LPAR isolation with assigned information memoryspace" (I/O adapter LPAR isolation with allocated memory space), issued by thomas a.gregg at 11/10/2009, describes a data processing system and method of isolating multiple I/O adapters in a system. The data processing system also includes a set of processors that communicate with the I/O adapters using a PCIe protocol. Each I/O adapter has a respective ID. In a preferred embodiment, the command issued by the I/O adapter includes a PCIe defined requestor ID field that includes one or more requestor IDs of the I/O adapter. ReqID may be used as an input to a CAM that provides an index to the TVT to identify a unique and independent system memory space for the I/O adapter.

U.S. patent No. 7,530,071 entitled "facility access to input/output resources via I/availability share multipleconsumer partitions," issued by Billau et al on 5/5 of 2009, describes providing at least one input/output (I/O) firmware partition in a partitioned environment to facilitate access to I/O resources owned by the at least one I/O firmware partition. The I/O resources of the I/O firmware partition are shared by one or more other partitions of the environment (referred to as guest partitions). The client partition uses the I/O firmware to access the I/O resources. Since the I/O firmware partitions are responsible for providing access to the I/O resources owned by those partitions, the client partitions are freed from this risk, reducing the load and cost in the client partitions.

Us published patent No. 2009/0240849a1 entitled "system and method for distributing virtual input/output operations across multiple logical partitions," published by Corneli et al on 24/9/2009, describes a distributed virtual I/O tool to replace a dedicated VIO server LPAR by distributing virtual I/O functions across multiple application LPARs connected by a high-speed communication channel. The logical I/O is distributed among the available LPARs. The distributed virtual I/O tool assigns (assign) each I/O request to the appropriate I/O device. The distributed virtual I/O tool monitors each I/O request and reallocates I/O devices when a particular device is in performance focus or when a device is no longer available.

Disclosure of Invention

According to aspects of the invention, access to I/O adapters is controlled such that only authorized configurations can access a given I/O adapter (e.g., adapter functionality). In one embodiment, control is performed in those computing environments that do not use, for example, memory mapped I/O.

The shortcomings of the prior art are overcome and advantages are provided through the provision of a computer program product for controlling an adapter to a computing environment. The computer program product includes a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. For example, the method includes executing an instruction including a request to configure access to an adapter, the adapter identified by a function handle that provided the request, the executing including a processor using the function handle to obtain a function table entry for the adapter, the function table entry including information associated with the adapter; determining whether to allow the configuration to access the adapter based on information in a function table entry; and in response to determining that the configuration is allowed to access the adapter, allowing access to the adapter.

Methods and systems relating to one or more aspects of the present invention are also described and claimed herein.

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

Drawings

One or more aspects of the present invention are particularly pointed out and distinctly claimed as examples of the claims at the conclusion of the specification. The above and other objects, features and advantages of the present invention will become apparent from the following detailed description when taken in conjunction with the accompanying drawings, in which:

FIG. 1A depicts one embodiment of a computing environment to incorporate and use one or more aspects of the present invention;

FIG. 1B depicts another embodiment of a computing environment to incorporate and use one or more aspects of the present invention;

FIG. 1C illustrates an example of a computing environment in which each adapter function of a plurality of adapter functions has a function table entry associated therewith in accordance with an aspect of the present invention;

FIG. 2A illustrates one example of a function table entry used in accordance with an aspect of the present invention;

FIG. 2B depicts one embodiment of a function handle used to locate a function table entry, in accordance with an aspect of the present invention;

FIG. 3A depicts one embodiment of an operating system executing a PCI load instruction to access a particular PCI function, in accordance with an aspect of the present invention;

FIG. 3B illustrates another example of an operating system issuing PCI store instructions for a particular PCI function in accordance with an aspect of the present invention;

FIG. 4 depicts one embodiment of the logic to control operating system access to particular adapter functions, in accordance with an aspect of the present invention;

FIG. 5A depicts one embodiment of call logic processor instructions, used in accordance with an aspect of the present invention;

FIG. 5B depicts one embodiment of a request block used by the Call logical processor instructions of FIG. 5A, in accordance with an aspect of the present invention;

FIG. 5C depicts one embodiment of a response block provided by the Call logical processor instructions of FIG. 5A, in accordance with an aspect of the present invention;

FIG. 6 depicts one embodiment of the logic to implement PCI functionality, in accordance with an aspect of the present invention;

FIG. 7A depicts one embodiment of a Modify PCI function controls instruction, used in accordance with an aspect of the present invention;

FIG. 7B depicts one embodiment of fields used by the Modify PCI function controls instruction of FIG. 7A, in accordance with an aspect of the present invention;

FIG. 7C depicts one embodiment of another field used by the Modify PCI function controls instruction of FIG. 7A, in accordance with an aspect of the present invention;

FIG. 7D depicts one embodiment of the contents of a Function Information Block (FIB), used in accordance with an aspect of the present invention;

FIG. 8 depicts one embodiment of an overview of the logic to modify PCI function control, in accordance with an aspect of the present invention;

FIG. 9A depicts one embodiment of a PCI load instruction, used in accordance with an aspect of the present invention;

FIG. 9B depicts one embodiment of the fields used by the PCI load instruction of FIG. 9A, in accordance with an aspect of the present invention;

FIG. 9C depicts one embodiment of another field used by the PCI load instruction of FIG. 9A, in accordance with an aspect of the present invention;

10A-10B illustrate one embodiment of logic to perform a PCI load operation, in accordance with an aspect of the present invention;

FIG. 11A depicts one embodiment of a PCI store instruction, as used in accordance with an aspect of the present invention;

FIG. 11B depicts one embodiment of fields used by the PCI store instruction of FIG. 11A, in accordance with an aspect of the present invention;

FIG. 11C depicts one embodiment of another field used by the PCI store instruction of FIG. 11A, in accordance with an aspect of the present invention;

12A-12B illustrate one embodiment of logic to perform a PCI store operation in accordance with an aspect of the present invention;

FIG. 13A depicts one embodiment of a PCI store Block instruction, as used in accordance with an aspect of the present invention;

FIG. 13B depicts one embodiment of fields used by the PCI store Block instruction of FIG. 13A, in accordance with an aspect of the present invention;

FIG. 13C depicts one embodiment of another field used by the PCI store Block instruction of FIG. 13A, in accordance with an aspect of the present invention;

FIG. 13D depicts one embodiment of yet another field used by the PCI store Block instruction of FIG. 13A, in accordance with an aspect of the present invention;

14A-14B illustrate one embodiment of logic to perform PCI store block operations in accordance with an aspect of the present invention;

FIG. 15 depicts one embodiment of a computer program product incorporating one or more aspects of the present invention;

FIG. 16 depicts one embodiment of a host computer system to incorporate and use one or more aspects of the present invention;

FIG. 17 depicts another embodiment of a computer system to incorporate and use one or more aspects of the present invention;

FIG. 18 illustrates another example of a computer system including a computer network that incorporates and uses one or more aspects of the present invention;

FIG. 19 depicts one embodiment of various elements of a computer system incorporating and using one or more aspects of the present invention;

FIG. 20A depicts one embodiment of an execution unit of the computer system of FIG. 19 to incorporate and use one or more aspects of the present invention;

FIG. 20B depicts one embodiment of a branching unit of the computer system of FIG. 19 incorporating and using one or more aspects of the present invention;

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

FIG. 21 illustrates one embodiment of an emulated host computer system incorporating and using one or more aspects of the present invention.

Detailed Description

According to an aspect of the invention, access to the adapter by the configuration is controlled. In particular, a capability is provided to control access such that only authorized configurations are able to access a specified adapter, such as a specified adapter function (e.g., a PCI function). For example, the configuration is an operating system, a processor, a logical partition, an operating system executing in a logical partition, a pageable storage mode guest (e.g., guest operating system), and the like. As used herein, the term operating system includes device drivers.

In one example, inA pageable guest is interpretively executed at level 2 of interpretation via a Start Interpretive Execution (SIE) instruction. For example, a Logical Partition (LPAR) hypervisor (hypervisor) executes the SIE instruction to begin a physical, fixed logical partition in memory. If it is notIs the operating system in the logical partition that issues the SIE instruction to execute its guest (virtual) machine in its V = V (virtual) storage. Thus, the LPAR hypervisor uses the level 1SIE, andthe hypervisor uses level 2 SIE.

Moreover, as used herein, the term "adapter" includes any type of adapter (e.g., storage adapter, processing adapter, network adapter, cryptographic adapter, PCI adapter, other types of input/output adapters, etc.). In one embodiment, an adapter includes an adapter function. However, in other embodiments, an adapter may include multiple adapter functions. One or more aspects of the present invention may be applied regardless of whether an adapter includes one adapter function or multiple adapter functions. In one embodiment, if the adapter includes multiple adapter functions, then the control capabilities herein apply to each adapter function in accordance with an aspect of the present invention. In the examples presented herein, the adapter is used interchangeably with the adapter function (e.g., PCI function) unless otherwise noted.

Further, the term firmware, as used further below, includes microcode, millicode (millicode), and/or macrocode of a processor, for example. It includes, for example, hardware-level instructions and/or data structures for implementing higher-level machine code. In one embodiment, it comprises, for example, proprietary (proprietary) code that is typically delivered as microcode that includes trusted software or microcode that is specific to the underlying hardware and controls operating system access to system hardware.

One embodiment of a computing environment to incorporate and use one or more aspects of the present invention is described with reference to FIG. 1A. In one example, computing environment 100 is provided by International Business machines corporationAnd (4) a server.The server is based on the service provided by International Business machines corporationAboutDetails of (A) are published in IBMThe publication is entitled "z/Architecture principles of operation", IBM publication No. SA22-7832-07, month 2 2009.Andis a registered trademark of international business machines corporation, armonk, new york. Other names used herein may be registered trademarks, trademarks or product names of International Business machines corporation or other companies.

In one example, computing environment 100 includes one or more Central Processing Units (CPUs) 102 coupled to a system memory 104 (also referred to as main memory) via a memory controller 106. To access system memory 104, central processing unit 102 issues a read or write request that includes an address that is used to access system memory. The address included in the request is typically not directly usable to access system memory, and therefore, it is converted to an address that is directly usable to access system memory. The address is translated via a translation mechanism (XLATE) 108. For example, addresses are translated from virtual addresses to real or absolute addresses using, for example, Dynamic Address Translation (DAT).

A request including an address (translated if necessary) is received by memory controller 106. In one example, the memory controller 106 contains hardware and is used to arbitrate for access to system memory and to maintain memory coherency. This arbitration is performed for requests received from the CPU102 and requests received from one or more adapters 110. Similar to a central processing unit, the adapter issues a request to system memory 104 to obtain access to the system memory.

In one example, adapter 110 is a Peripheral Component Interconnect (PCI) or PCI express (PCIe) adapter that includes one or more PCI functions. The PCI function issues a request that is routed to an input/output hub 112 (e.g., a PCI hub) via one or more switches (e.g., PCIe switches) 114. In one example, the input/output hub includes hardware including one or more state machines and is coupled to the memory controller 106 via an I/O-to-memory bus 120.

The input/output hub includes, for example, a root complex (rootcomplex) 116 that receives requests from switches. The request includes an input/output address that is provided to the address translation and protection unit 118, and the address translation and protection unit 118 accesses information for the request. As examples, the request may include an input/output address used to perform a Direct Memory Access (DMA) operation or request a Message Signaled Interrupt (MSI). The address translation and protection unit 118 accesses information for the DMA or MSI request. As a particular example, for DMA operations, information may be obtained to translate addresses. The translated address is then forwarded to the memory controller to access the system memory.

In one example, information for DMA or MSI requests issued by an adapter is obtained from a device table entry located in the I/O hub (e.g., in an address translation and protection unit). The device table entries include information for adapters, and each adapter has at least one device table entry associated therewith. For example, there is one device table entry per address space assigned to an adapter. For requests issued from an adapter, the device table entry is located using the request id provided in the request.

In a further embodiment of a computing environment, a central processing complex is coupled to the memory controller 106 in addition to or in place of one or more CPUs 102, as shown in FIG. 1B. In this example, the central processing complex 150 includes, for example, one or more partitions or regions 152 (e.g., logical partitions LP 1-LPn), one or more central processors (e.g., CP 1-CPm) 154, and a hypervisor 156 (e.g., a logical partition manager), each of which is described below.

Each logical partition 152 can function as a separate system. That is, each logical partition may be independently reset, utilize an operating system or hypervisor (e.g., as provided by International Business machines corporation of Armonk, N.Y.)) An initial load is made (if needed) and the operation is performed with a different program. An operating system, hypervisor, or application running in a logical partition appears to have access to a complete and complete system, but only a portion of it is available. The hardware and licensed internal code (also referred to as microcode or millicode) keep programs in the logical partitions from interfering with programs in different logical partitions. This allows multiple different logical groups to operate on a single or multiple physical processors in a time sliced manner. In this particular example, each logical partition has a resident operating system 158, which may be different for one or more logical partitions. In one embodiment, the operating system 158 is provided by International Business machines corporation of Armonk, N.YOr the zLinux operating system.Andis a registered trademark of international business machines corporation of armonk, new york.

Central processors 154 are physical processor resources allocated to logical partitions. For example, logical partition 152 includes one or more logical processors, each of which represents all of the physical processor resources 154 allocated to the partition or a share of the physical processor resources 154. The underlying (undersying) processor resources may be dedicated to the partition or shared with another partition.

The logical partitions 152 are managed by a hypervisor 156 implemented by firmware running on the processors 154. Logical partition 152 and hypervisor 156 each comprise one or more programs that reside in respective portions of the central storage associated with the central processors. One example of hypervisor 156 is a processor resource/system manager (PR/SM) provided by International Business machines corporation of Armonk, N.Y..

Although a central processing complex with logical partitions is described in this example, one or more aspects of the present invention may be incorporated into or used by other processing units, including single or multiple ones of multiple processing units that are not partitioned. The central processing complex described herein is merely an example.

As described herein, an adapter may include one or more adapter functions. Additional details regarding the adapter function are described with reference to FIG. 1C. As shown in FIG. 1C, each adapter function 180 is coupled to I/O hub 112 via one or more PCI switches 114. I/O hub 112 is coupled to logical partitions 152 via an I/O-to-memory bus 120. In this example, the memory controller is not shown, but may be used. The I/O hub may be coupled to the logical partitions directly or via a memory controller.

Each adapter function 180 has associated with it a function table entry 182 that includes information related to its associated adapter function. For example, as shown in FIG. 2A, the function table entry 182 has a plurality of fields including, for example:

area number 202: this field includes a value used in a logically partitioned environment to specify a region or logical partition. The value of this field indicates which region (e.g., the operating system within the region) owns or has the adapter function associated with this function table entry.

In a further embodiment, the region number may be used to identify the configuration regardless of whether it is a logical partitioned environment. For example, it may be another configuration identifier or an operating system identifier.

The client identifier 204: this field is used to identify the client that is allowed to access this adapter function when the system is in pageable storage mode;

status indicator 206: it provides the following indication: whether the function table entry itself is valid, whether the function is enabled, and/or whether the function is in an error state, etc.;

function type 208: which provides an indication of the type of adapter function (e.g., one function per adapter; multiple functions per adapter, etc.);

requester id (rid) 210: which is an identifier of an adapter function that may include an adapter bus number, a device number, and a function number. This field is used for access by the configuration of the configuration space of the adapter function.

As shown in FIG. 3A, the adapter function includes memory 300 having a plurality of address spaces including, for example, a configuration space (e.g., a PCI configuration space for a PCI function), an I/O space (e.g., a PCII/O space), and one or more memory spaces (e.g., a PCI memory space).

The configuration space is addressed by specifying it in an instruction issued by the configuration to the adapter function. Also specified in the instruction are an offset in the configuration space and a function handle for locating the appropriate function table entry that includes the RID. The firmware receives the instruction and determines whether it is for a configuration space. Thus, it uses the RID to generate requests to the I/O hub, and the I/O hub creates requests to access the adapter. The location of the adapter is based on the RID and the offset specifies an offset in the configuration space of the adapter. For example, the offset specifies an offset within a register number in the configuration space.

Base address registers (1 to n) 212: one or more base address registers may exist and each is used to indicate the base address of the memory space or I/O address space of the adapter function. Which is used to access the I/O space and/or memory space of the adapter function.

For example, the offset provided in the instruction accessing the adapter function is added to the value in the base address register associated with the address space specified in the instruction obtaining the address to be used to access the adapter function. The address identifier provided in the instruction identifies the address space in the adapter function to be accessed and the corresponding BAR to be used.

Device table indices (1 to n) 214 (fig. 2A): there may be one or more device table indices, and each index is an index in the device table that locates a Device Table Entry (DTE). There may be one or more device table entries per adapter function, and each entry includes information associated with its adapter function, including information for handling requests by the adapter function (e.g., DMA requests, MSI requests) and information related to requests to the adapter function (e.g., PCI instructions). Each device table entry is associated with an address space in system memory allocated to the adapter function. The information included in the DTE may depend on operations supported by or enabled for the adapter function (described in more detail below); and

internal routing information 216: this information is used to perform a specific route to the adaptation. Which includes, by way of example, node, processor chip, and hub addressing information.

The function table entry may include more, less, or different information. The information included may depend on operations supported by or enabled for the adapter function (described in more detail below).

To access a particular function table entry for a given adapter function, function handle 184 (FIG. 1C) is used. In one example, one or more bits of the function handle are used as an index into the function table to locate a particular function table entry. There is a function handle 184 for each adapter function. In one particular example, the function handle includes a plurality of parameters. As shown in FIG. 2B, function handle 184 includes, for example, an enable indicator 252 that indicates whether the handle is enabled; a function number 254 that identifies the function (this is a static identifier and can be used as an index into the function table); and an instance number 256 indicating the particular instance of the function handle.

As described above, the adapter function may issue requests, such as memory access requests, interrupt requests, and the like. Further, the configuration may issue requests to the adapter function. According to an aspect of the invention, these configuration requests access the adapter or modify control parameters associated with the adapter via specific instructions. Example instructions include a PCI load, a PCI store, and a modify PCI function control, to name a few. These instructions are specific to the I/O infrastructure (e.g., PCI).

In one example, as shown in FIG. 3A, a load instruction 312 (e.g., a PCI load) is issued by an operating system executing with CPU310 to access one of the address spaces of memory 300 of a function. There may be multiple adapter functions in the system and only one operating system may be allowed to access a given adapter. When the operating system issues a PCI load instruction, access restrictions may be enforced, for example, by firmware, to ensure that the operating system issuing the instruction is allowed to access the address space within the adapter function.

In a further example, an operating system executing in CPU310 issues a store instruction 314 (e.g., PCI store), which may also access one of the address spaces. There are other adapter instructions that also need to be controlled so that only the operating system (or other configuration) can access the adapter functions assigned to it.

One embodiment of controlling operating system access to adapter functionality is described with reference to FIG. 4. Although this example describes operating system access, it may be used by other configurations.

Referring to FIG. 4, initially, at step 400, policies are set by a system administrator or client associating each PCI function with a particular configuration (e.g., a particular operating system, a particular logical partition, etc.) that allows access to the adapter function. The policy is reconfigurable and maintained in an I/O configuration dataset located in secure memory, for example.

At system initialization, at step 402, firmware (e.g., trusted firmware) performs an I/O architecture base device (infrastructure) bus walk (debug) to determine what adapter functionality is included (e.g., plugged in) in the architecture base device. If the platform does not support the adapter identified by its vital product data, the firmware will not consider the adapter as part of the infrastructure. During such a bus walk, the firmware performs a certain number of configurations, step 403. The configuration includes initializing the PCIe switch 114 with routing information (e.g., bus number and address information) that will allow successful routing of packets to and from the adapter function. At this point, the configuration space of the supported adapters may also be initialized with the supplicant ID of the supported adapters and BAR information, where the BAR information also coincides with routing information configured in the switch. Thereafter, a function table entry is created for each supported adapter function and the function table entry is populated with some information, STEP 404. For example, the firmware sets the previously configured BAR information and the requester ID in the function table entry. Based on the policy, the region number set in each function table entry that indicates which logical grouping, and therefore which operating system, accesses the adapter function corresponding to the function table entry. In further embodiments, where the computing environment is not logically partitioned, the region number may be replaced by another indicator that indicates the operating system rather than logical partitioning. Other indicators may also be used in other types of configurations.

Thereafter, the operating system issues a query to determine which adapter functions (e.g., those allocated and possibly allocated) it has accessed, STEP 406. In response to the query, the firmware returns a list of one or more adapter functions. As an example, the firmware scans the function table, looking up all function table entries with a region number that matches the region number of the requesting operating system; and returns a list of adapter functions for which the region table entry matches. (in another embodiment, a partial list may be returned). For each adapter function included in the list, a function handle is provided in the list.

At some point, the operating system attempts to access the adapter function via, for example, an instruction (e.g., query the adapter function; access the address space of the function; or create or modify a device table entry for the adapter function; etc.), STEP 408. The operating system indicates in the instruction the adapter function accessed via the function handle. The firmware then uses this function handle to locate the function table entry corresponding to the adapter function, STEP 410. The region number in the function table entry is compared to the region number where the operating system resides, INQUIRY 412. If they do not match, then access is denied (e.g., instruction execution is prevented), step 414. If, however, they match, then a further determination is made, in one example, whether access should be blocked for a different reason, INQUIRY 416. For example, the state stored in the function table entry is used to determine whether the operating system issues an instruction to be blocked and to perform firmware privileged operations that affect the adapter function, such as recovery, firmware download, and the like.

If there is an indication that access should be blocked, a further determination is made as to whether the blocking is temporary, INQUIRY 418. That is, if the adapter function is only temporarily unavailable, as indicated by a status in the function table entry, for example, the busy signal may be utilized to complete the instruction, step 420, and it may be attempted again. If, however, the adapter function is not only temporarily blocked, then access is denied, step 422.

Returning to query 416, if access should not be blocked, then access is allowed, step 424. For example, instructions are allowed to execute. This ends the processing.

In addition to the above, in a further example, if it is determined that the region number in the function table entry matches the region number of the operating system, additional validation may be performed to allow the guest (e.g., the VM guest) direct access to the guest-owned adapter. In this example, a check is performed to see if the client has accessed the adapter. For example, the function table entry checks the client id. If the client id is stored in the entry, processing continues; if not, the request is denied.

The access control capability described above is used for instructions issued by the configuration to the adapter function, such as PCI load, PCI store block, modify PCI function control, and various call logic processor CLP instructions, for example, to query or enable/disable the adapter function. In this example, the instruction is a PCI instruction, since the adapter function is a PCI adapter function. However, in other examples, other I/O architecture specific instructions may be used depending on the architecture of the adapter function.

Additional details regarding some of the instructions are described below. For example, to use the PCI function, it is enabled. For example, an operating system that wishes to use PCI functions performs a query to determine one or more functions that are appropriate for use (based on the I/O configuration), and one of those functions is to be enabled. In one example, functions are enabled using a set of call logic processor instructions, PCI function instructions. One embodiment of this instruction is shown in FIG. 5A. As shown, in one example, the call logic processor instruction 500 includes an opcode 502 indicating that it is a call logic processor instruction; and an indication for command 504. In one example, this indication describes the address of the request block of the command to be executed. One embodiment of such a request block is shown in FIG. 5B.

As shown in FIG. 5B, in one example, request block 520 includes a number of parameters, such as a length field 522, indicating the length of the request block; a command field 524 indicating an aggregate PCI function command; PCI function handle 526, which is a handle provided to an enable or disable function; an opcode 528 to specify an enable or disable operation; and a plurality of DMA address spaces (DMAAS) 530 that indicate the requested address space number associated with a particular PCI function. More, less or different information may be included in other embodiments. For example, a guest identity (identity) is provided in a virtual environment where a host of a pageable storage mode guest issues instructions. Other variations are also possible.

In response to issuing and processing the call logic processor instruction, a response block is returned and the information included in the response block depends on the operation to be performed. One embodiment of a response block is shown in FIG. 5C. In one example, response block 550 includes: a length field 552 indicating the length of the response block; a response code 554 indicating the status of the command; and a PCI function handle 556, which identifies a PCI function. In response to the enable command, the PCI function handle is an enable handle of the PCI function. Further, upon completion of the disable operation, the PCI function handle is a generic handle that may be enabled by an enabling function in the future.

One embodiment of the logic to enable the PCI function is described with reference to FIG. 6. In one example, the logic is initiated in response to issuing a call logic processor instruction, wherein the command is set to an aggregate PCI function command and the opcode is set to an enable function. The logic is executed by the processor, for example, in response to an operating system or a device driver of the operating system being authorized to execute the logic that issues instructions. In other embodiments, the logic may be executed without the use of call logic processor instructions.

Referring to FIG. 6, initially, a determination is made as to whether the handle provided in the request block of the Call logic processor instruction is a valid handle, INQUIRY 600. I.e., does the handle point to a valid entry in the function table? Or it is outside the range of valid entries (e.g., the function number portion of the handle specifies the installed function). If the handle is unknown, a corresponding response code is provided indicating that the handle is not recognized, STEP 602. However, if the handle is known, then a further query is made as to whether the handle is enabled, INQUIRY 604. This determination is made by examining an enable indicator in the PCI function handle. If an indication is set indicating that the handle is enabled, then a response code is returned as indicated, STEP 606.

However, if the handle is known and not enabled (i.e., valid for implementation), then a determination is made as to whether the requested address space number assigned to the PCI function is greater than a maximum value, INQUIRY 608. To make this determination, the DMA address space number specified in the request block is compared to a maximum value (provided based on policy, in one example). If the address space number is greater than the maximum value, then a response code indicating an invalid value for the DMA address space is provided, STEP 610. Otherwise, a determination is made as to whether the requested address space number is available, INQUIRY 612. This determination is made by checking whether there is a device table entry available for the requested address space number. If the requested address space number is not available, a response code is returned indicating that there are not enough resources, STEP 614. Otherwise, processing continues to enable the PCI function.

The handle provided is used to locate the function table entry, step 616. For example, one or more specified bits of the handle are used as an index into the function table to locate a particular function table entry. In response to locating the appropriate function table entry, a determination is made as to whether the function is enabled, INQUIRY 618. This determination is made by checking the enable indicator in the function table entry. If the function has been enabled (i.e., the indicator is set to 1), then a response code is returned indicating that the PCI function has been in the requested state, STEP 620.

If the function has not been enabled, then processing continues to determine if the function is in a permanent error state, INQUIRY 622. If the permanent error status indicator in the function table entry indicates that it is in a permanent error state, then a response code indicating this is returned, step 624. However, if the function is not in a permanent error state, then a further determination is made as to whether error recovery has been initiated for the function, INQUIRY 626. If the recovery initiation indicator in the function table entry is set, a response code indicating that recovery has been initiated is provided, step 628. Otherwise, a further query is made as to whether the PCI function is busy, INQUIRY 630. Again, if the check of the busy indicator in the function table entry indicates that the PCI function is busy, then such an indication is provided, step 632, whereas if the PCI function is not in a permanent error state, no recovery is initiated and it is not busy, then a further query is made whether the operating system is allowed to enable the PCI function, step 634.

In one example, the permission check includes verifying the region number in the FTE with the region number of the operating system issuing the instruction. If they are not equal, the operating system is not allowed. If they are equal, then the allow indicator in the function table entry is checked. If the function table entry based permission indicator does not permit, then a response code indicating an unauthorized action is provided, step 636. If all tests are successfully passed, however, a further determination may be made as to whether there are any DTEs available for such PCI functions, INQUIRY 638. As an example, the determination that DTEs are available may be based on DTEs that are not currently enabled in the I/O hub. Thus, policies may be applied to further limit the number of DTEs that may be used to specify an operating system or logical partition. Any available DTE that can access the adapter can be assigned. If there are no available DTEs, a response code is returned indicating that one or more requested DTEs are not available, STEP 640.

If a DTE is available, then a number of DTEs corresponding to the requested address space number are allocated and enabled, STEP 642. In one example, the enabling includes setting an enable indicator in each DTE to be enabled. Further, in this example, the enabling includes establishing a Content Addressable Memory (CAM) to provide an index to each DTE. For example, for each DTE, an entry in the CAM is loaded with the index, and the CAM facilitates the location of the DTE.

In addition, a DTE is associated with the conceptual table entry, STEP 644. This includes, for example, including each DTE index in the function table entry. The function is then marked as enabled by setting an enable indicator in the function table entry, STEP 646. In addition, the enable bit in the handle is set and the instance number is updated, step 648. This enable handle, which allows use of the PCI adapter, is then returned, STEP 650. For example, in response to enabling the function, registration for address translation and interrupts may be performed, DMA operations may be performed by the PCI function and/or load, store, and store block instructions may be issued to the function.

As indicated above, after the function is enabled, various operating parameters are set in the DTE and/or FTE by modifying the PCI function control instructions. An example of modifying the PCI function control instruction will be described with reference to fig. 7A to 7D.

Referring to FIG. 7A, a Modify PCI function controls instruction 700 includes, for example, an opcode 702 indicating the Modify PCI function controls instruction; a first field 704 specifying where various information is included, the information being about the adapter function for which the operational parameters are being established; and a second field 706 that indicates the location from which a PCI Function Information Block (FIB) is obtained. The contents of the location specified by fields 1 and 2 will be further described below.

In one embodiment, field 1 specifies a general register that includes various information. As shown in FIG. 7B, the contents of the register include, for example, a function handle (handle) 710 that identifies the handle of the adapter function on which the modify instruction is executed; an address space 712 specifying an address space in system memory associated with the adapter function specified by the function handle; an operation control 714 that specifies an operation to be performed for the adapter function; and a state 716 that provides, in a predetermined code, a state about the instruction when the instruction is completed.

In one example, as shown in FIG. 7C, field 2 indicates the logical address 720 of the PCI Function Information Block (FIB), which includes information about the adapter function. The function information block is used to update the device table entry and/or function table entry (or other location) associated with the adapter function. This information is stored in the FIB during initialization and/or configuration of the adapter, and/or in response to certain events.

Further details regarding the Functional Information Block (FIB) are described with reference to fig. 7D. In one embodiment, the function information block 750 includes the following fields:

format 751: this field specifies the format of the FIB.

Interception control 752: this field is used to indicate whether guest execution of a particular instruction by a pageable mode guest (pageable modeguest) results in instruction interception;

error indication 754: this field includes error status indications for direct memory access and adapter interruptions. When the bit is set (e.g., 1), one or more errors are detected when performing direct memory access or adapter interception for the adapter function;

load/store block 756: this field indicates whether the load/store operation is blocked;

PCI function valid 758: this field includes enable controls for the adapter function. When the bit is set (e.g., 1), the adapter function is considered enabled for I/O operations;

address space registration 760: this field includes direct memory access enable control for the adapter function. When this field is set (e.g., 1), direct memory access is enabled;

page size 761: this field indicates the size of the page or other unit of storage to be accessed by the DMA memory access;

PCI Base Address (PBA) 762: this field is the base address for the address space in system memory allocated to the adapter function. It represents the lowest virtual address that the adapter function is allowed to use in direct memory access to the specified DMA address space;

PCI address boundary (PAL) 764: this field indicates the highest virtual address that the adapter function is allowed to access within the specified DMA address space;

input/output address translation pointer (IOAT) 766: the input/output address translation pointer specifies the first of any translation tables used by PCI virtual address translation, or it may directly specify the absolute address of the memory frame as the result of the translation;

interrupt Subclass (ISC) 768: this field includes an interrupt subclass for giving adapter interrupts for adapter functions;

number of interruptions (NOI) 770: this field specifies the number of different interrupt codes that are acceptable for the adapter's function. This field also defines in bits the size of the adapter interrupt bit vector specified by the adapter interrupt bit vector address and the adapter interrupt bit vector offset field;

adapter interrupt bit vector Address (AIBV) 772: this field specifies the address of the adapter interrupt bit vector for the adapter function. The vector is used in the interrupt processing;

adapter interrupt bit vector offset 774: this field specifies the offset of the first adapter interrupt bit vector bit for the adapter function;

adapter interrupt summary bit Address (AISB) 776: this field provides an address specifying an adapter interrupt summary bit that is optionally used in interrupt processing;

adapter interrupt summary bit offset 778: this field provides an offset into the adapter interrupt summary bit vector;

function Measurement Block (FMB) address 780: this field provides the address of the function measurement block for collecting measurements on the adapter function;

function measurement block key (key) 782: this field includes an access key to access the functional measurement block;

summary bit notification control 784: this field indicates whether there is a summary bit vector being used;

instruction authorization token 786: this field is used to determine whether a pageable storage mode guest (e.g., a V = V guest) is authorized to execute PCI instructions without host intervention; and

address translation format 787: this field indicates the selected format (e.g., indication of the segment table, region (region) third, etc.) for translating the address of the highest level translation table to be used in the translation.

The information in the functional information block is obtained during configuration, initialization, and/or the occurrence of a particular event.

In accordance with an aspect of the present invention, the function information block specified in the Modify PCI function controls instruction is used to modify the selected device table entry, function table entry, and/or other firmware controls associated with the adapter function specified in the instruction. Certain services are provided to the adapter by modifying device table entries, function table entries, and/or other firmware controls. These services include, for example, adapter interruptions; address translation; resetting the error state; reset load/store block; setting functional measurement parameters; and setting interception control.

One embodiment of the logic associated with modifying a PCI function control instruction is described with reference to FIG. 8. In one example, the instructions are issued by an operating system (or other configuration) and executed by a processor (e.g., firmware) executing the operating system. In the example herein, the instruction and adapter functions are PCI based. However, in other embodiments, different adapter structures and corresponding instructions may be used.

In one example, the operating system provides the following operands to the instruction (e.g., in one or more registers specified by the instruction); PCI function handles; a DMA address space identifier; operation control; and the address of the functional information block.

Referring to FIG. 8, initially, a determination is made as to whether a facility (facility) is installed that allows modification of the PCI function control instructions, INQUIRY 800. This determination is made, for example, by examining an indicator stored, for example, in a control block. If the tool is not installed, an exception condition is provided, STEP 802. Otherwise, a determination is made as to whether the instruction was issued by a pageable storage mode guest (or other guest), INQUIRY 804. If so, the host operating system will emulate the operation for the guest, step 806.

Otherwise, a determination is made as to whether one or more operands are aligned, INQUIRY 808. For example, it is determined whether the address of the functional information block is at a doubleword boundary. In one example, this is optional. If the operands are not aligned, an exception condition is provided, STEP 810. Otherwise, a determination is made as to whether the functional information block is accessible, INQUIRY 812. If not, an exception condition is provided, step 814. Otherwise, a determination is made as to whether the handle provided in the operand of the modify PCI function control instruction is enabled, INQUIRY 816. In one example, this determination is made by examining an enable indicator in the handle. If the handle is not enabled, an exception condition is provided, step 818.

If the handle is enabled, the handle is used to locate the function table entry, STEP 820. That is, at least a portion of the handle is used to index into the function table to locate the function table entry corresponding to the adapter function for which the operating parameters are to be established.

A determination is made as to whether a function table entry is found, INQUIRY 822. If not, an exception condition is provided, step 824. Otherwise, a determination is made as to whether the operating system is authorized, INQUIRY 826. In one example, this includes verifying the region number in the FTE with the region number of the operating system that issued the instruction. If they are not equal, the operating system is not authorized. If they are equal, a further determination is made as to whether the configuration from which the instruction was issued is a guest. If so, an exception condition is provided (e.g., interception to the host), step 828. If the configuration is not a customer, the query may be ignored, or other authorizations may be checked, if specified.

A determination is then made as to whether the function is enabled, INQUIRY 830. In one example, this determination is made by checking an enable indicator in the function table entry. If it is not enabled, an exception condition is provided, step 832.

If the function is enabled, a determination is made as to whether recovery is active, INQUIRY 834. If the recovery is active as determined by the recovery indicator in the function table entry, an exception condition is provided 836. If, however, recovery is not active, a further determination is made as to whether the function is busy, 838. This determination is made by looking up the busy indicator in the function table entry. If the function is busy, a busy condition is provided, step 840. With the busy condition, the instruction may be retried instead of giving up it.

If the function is not busy, a further determination is made as to whether the function information block format is valid, INQUIRY 842. For example, the format field of the FIB is examined to determine if the format is supported by the system. If it is not valid, an exception condition is provided, step 844. If the function information block format is valid, a further determination is made as to whether the operation control specified in the operand of the instruction is valid, INQUIRY 846. That is, whether the operation control is one of the specified operation controls for the instruction. If it is not valid, an exception condition is provided, step 848. However, if the operation control is valid, the specified specific operation control is continued to be processed.

May specify include, for example, register/unregister address translation; register/deregister adapter interruption; setting interception control; resetting the error state; resetting various operations of the load/store block indicator, etc. For each of these operations, operational parameters associated with the operation are copied from the FIB to the DTE and/or the FTE (or other location).

After initialization, the client may execute PCI load, PCI store, and PCI store block instructions, each of which is described below.

Referring initially to FIG. 9A, one embodiment of a PCI load instruction is illustrated. As shown, PCI load instruction 900 includes, for example, opcode 902, indicating a PCI load instruction; a first field 904 specifying a location where data retrieved from the adapter function is to be loaded; and a second field 906 specifying a location including various information related to the adapter function from which the data is loaded. The contents of the locations specified by fields 1 and 2 are further described below. In one example, field 1 specifies a general purpose register, and as shown in FIG. 9B, the contents 904 of the register comprise a contiguous range of one or more bytes loaded from the adapter location specified in the instruction. In one example, data is loaded into the rightmost byte position of the register.

In one embodiment, field 2 indicates a general register pair that includes various instructions. As shown in fig. 9C, the contents of the register include, for example:

enable handle 910: this field is the enable function handle of the adapter function from which the data was loaded;

address space 912: this field identifies the address space within the adapter function from which the data is loaded;

offset 914 within address space: this field specifies an offset within the specified address space from which the data is loaded;

length field 916: this field specifies the length of the load operation (e.g., the number of bytes to be loaded); and

status field 918: this field provides a status code that can be used when the instruction ends with a predetermined condition code.

In one embodiment, the bytes loaded from the adapter function are contained within the integer limits of the adapter function's specified PCI address space. The integer bound size is, for example, a double word when the address space field specifies the memory address space. When the address space field specifies an I/O address space or a configuration address space, the integer bound size is, for example, a doubleword.

One embodiment of the logic associated with a PCI load instruction is described with reference to FIGS. 10A-10B. In one example, the instructions are issued by an operating system (or other configuration) and executed by a processor (e.g., firmware) executing the operating system. In the example herein, the instruction and adapter functions are PCI based. However, in other examples, different adapter architectures and corresponding instructions may be used.

To issue an instruction, the operating system provides the instruction (e.g., in one or more registers specified by the instruction) with the following operators: the PCI function handle, the PCI address space (PCIAS), the offset in the PCI address space, and the length of the data to be loaded. Upon successful completion of the PCI load instruction, the data is loaded in the location (e.g., register) specified by the instruction.

Referring to FIG. 10A, initially, a determination is made as to whether a facility is installed that allows PCI load instructions, INQUIRY 1000. This determination is made, for example, by examining an indicator stored in the control block. If no tools are installed, an exception condition is provided, step 1002. Otherwise, a determination is made as to whether the operator is aligned, INQUIRY 1004. For example, if certain operators need to be odd/even register pairs, a determination is made whether these requirements are met. If the operator is not aligned, an exception is provided, step 1006. Otherwise, if the tool is installed and the operators are aligned, a determination is made as to whether the handle provided in the operator of the PCI load instruction is enabled, INQUIRY 1008. In one example, this determination is made by examining an enable indicator in the handle. If the handle is not enabled, an exception condition is provided, STEP 1010.

If the handle is enabled, the handle is used to locate the function table entry, STEP 1012. That is, at least a portion of the handle is used as an index into the function table to locate the function table entry corresponding to the adapter function from which the data was loaded.

Thereafter, a determination is made as to whether the operating system is authorized, INQUIRY 1014. In one example, this includes verifying the region number in the FTE with the region number of the operating system that issued the instruction. If they are not equal, the operating system is not authorized. If they are equal, a further determination is made as to whether the configuration from which the instruction was issued is a guest. If so, an exception condition is provided, step 1016. If the configuration is not a customer, the query may be ignored, or other authorizations may be checked, if specified.

A determination is then made as to whether the function is enabled, INQUIRY 1018. In one example, this determination is made by checking an enable indicator in the function table entry. If it is not enabled, an exception condition is provided, step 1020.

If the function is enabled, a determination is made as to whether the address space is valid, INQUIRY 1022. For example, whether the specified address space is that of an adapter function and is appropriate for the instruction. If the address space is not valid, an exception condition is provided, step 1024. Otherwise, a determination is made whether to block the load/store, INQUIRY 1026. In one example, this determination is made by checking a status indicator in the function table entry. If the load/store is prevented, then an exception condition is provided, STEP 1028.

However, if the load/store is not blocked, a determination is made as to whether the restore is active, INQUIRY 1030. In one example, this determination is made by checking a recovery initiation indicator in the function table entry. If recovery is active, then an exception condition is provided, step 1032. Otherwise, a determination is made as to whether the function is busy, INQUIRY 1034. This determination is made by checking the busy indicator in the function table entry. If the function is busy, a busy condition is provided, step 1036. With the busy condition, the instruction may be retried instead of being discarded.

If the function is not busy, a further determination is made as to whether the offset specified in the instruction is valid, INQUIRY 1038. That is, the offset is combined with the length of the operation within the base address and the length of the address space as specified in the function table entry? If not, an exception condition is provided, step 1040. However, if the offset is valid, then a determination is made as to whether the length is valid, INQUIRY 1042. That is, the address space type, the offset within the address space, and the integer bound size are made length-efficient. If not, an exception condition is provided, step 1044. Otherwise, processing continues with the load instruction. (in one embodiment, the firmware performs the checks described above).

Continuing with FIG. 10B, a determination is made by the firmware to load the configuration address space whether or not to be used for the adapter function, INQUIRY 1050. That is, based on the configuration of the memory of the adapter function, is the particular address space provided in the instruction the configuration space? If so, the firmware performs various processes to provide the request to the hub coupled to the adapter function; the hub then routes the request to the function, step 1052.

For example, the firmware obtains the requestor ID from the function table entry pointed to by the function handle provided in the instruction operator. Further, based on information in the function table entry (e.g., internal routing information), the firmware determines the hub that received the request. That is, the environment may have one or more hubs, and the firmware determines the hub coupled to the adapter function. It then forwards the request to the hub. The hub generates a configuration read request packet that flows out of the PCI bus to the adapter function identified by the RID in the function table entry. The configuration read request includes the RID and an offset (i.e., data address) for retrieving data, as described below.

Returning to query 1050, if the specified address space is not a configuration space, then the firmware again performs various processes to provide the request to the hub, step 1054. The firmware uses the handle to select a function table entry and it obtains information from the entry that locates the appropriate hub. It also calculates the data address used in the load operation. The address is calculated by adding the BAR start address obtained from the function table entry (using the BAR associated with the address space identifier provided in the instruction) to the offset provided in the instruction. Providing the calculated data address to a hub. The hub then obtains the address and includes it in a request packet, such as a DMA read request packet, that is streamed over the PCI bus to the adapter function.

In response to receiving the request, either via step 1052 or step 1054, the adapter function retrieves the requested data from the particular location (i.e., at the data address) and returns the data in response to the request, step 1056, which forwards the response from the adapter function to the I/O hub. In response to receiving the request, the hub forwards the response to the initiating processor. The initiating processor then retrieves the data from the response packet and loads the data at the specified location specified in the instruction (e.g., field 1). the PCI load operation ends with an indication of success (e.g., a condition code set to zero).

In addition to a load instruction that fetches data from an adapter function and stores it in a specified location, another instruction that may be executed is a store instruction. The store instruction stores data at a specified location of the adapter function. One embodiment of a PCI store instruction is described with reference to FIG. 11A. As shown, PCI store instruction 1100 includes, for example, opcode 1102, indicating a PCI store instruction; a first field 1104 specifying a location including data to be stored at the adapter function; and a second field 1106 specifying a location including various information related to an adapter function to which data is to be stored. The contents of the locations specified by fields 1 and 2 are further described below.

In one example, field 1 specifies a general purpose register, and as shown in FIG. 11B, the contents 1104 of the register include one or more bytes of a contiguous range of data to be stored to a specified location of the adapter function. In one example, the data of the rightmost byte position of the register is stored.

In one embodiment, field 2 indicates a general register pair that includes various instructions. As shown in fig. 11B, the contents of the register include, for example:

enable handle 1110: this field is the enabled function handle of the adapter function to which the data is stored;

address space 1112: this field identifies the address space within the adapter function to which the data is stored;

offset in address space 1114: this field specifies an offset within the specified address space to which the data is stored;

length field 1116: this field specifies the length of the store operation (e.g., the number of bytes to be stored); and

status field 1118: this field provides a status code that can be used when the instruction ends with a predetermined condition code.

One embodiment of the logic associated with a PCI store instruction is described with reference to FIGS. 12A-12B. In one example, instructions are issued by an operating system and executed by a processor (e.g., firmware) executing the operating system.

To issue an instruction, the operating system provides the instruction (e.g., in one or more registers specified by the instruction) with the following operators: a PCI function handle, PCI Address space (PCIAS), an offset in PCI Address space, a length of data to be stored, and a pointer to data to be stored. Upon successful completion of the PCI store instruction, the data is stored in the location specified by the instruction.

Referring to FIG. 12A, initially, a determination is made as to whether a facility is installed that allows PCI store instructions, INQUIRY 1200. This determination is made, for example, by examining an indicator stored in the control block. If no tools are installed, an exception condition is provided, step 1202. Otherwise, a determination is made as to whether the operator is aligned, INQUIRY 1204. For example, if certain operators need to be odd/even register pairs, a determination is made whether these requirements are met. If the operator is not aligned, an exception is provided, step 1206. Otherwise, if the tool is installed and the operators are aligned, a determination is made as to whether the handle provided in the operator of the PCI store instruction is enabled, INQUIRY 1208. In one example, this determination is made by examining an enable indicator in the handle. If the handle is not enabled, an exception condition is provided, step 1210.

If the handle is enabled, the handle is used to locate the function table entry, STEP 1212. That is, at least a portion of the handle is used as an index into the function table to locate the function table entry corresponding to the adapter function to which the data is stored.

Thereafter, a determination is made as to whether the operating system is authorized, INQUIRY 1214. In one example, this includes verifying the region number in the FTE with the region number of the operating system that issued the instruction. If they are not equal, the operating system is not authorized. If they are equal, a further determination is made as to whether the configuration from which the instruction was issued is a guest. If so, an exception condition is provided, step 1216. If the configuration is not a customer, the query may be ignored, or other authorizations may be checked, if specified.

A determination is then made as to whether the function is enabled, INQUIRY 1218. In one example, this determination is made by checking an enable indicator in the function table entry. If it is not enabled, an exception condition is provided, step 1220.

If the function is enabled, a determination is made as to whether the address space is valid, INQUIRY 1222. For example, whether the specified address space is that of an adapter function and is appropriate for the instruction. If the address space is not valid, an exception condition is provided, STEP 1224. Otherwise, a determination is made whether to block the load/store, INQUIRY 1226. In one example, this determination is made by checking a status indicator in the function table entry. If the load/store is blocked, then an exception condition is provided, step 1228.

However, if the load/store is not blocked, a determination is made as to whether the restore is active, INQUIRY 1230. In one example, this determination is made by checking a recovery initiation indicator in the function table entry. If recovery is active, then an exception condition is provided, step 1232. Otherwise, a determination is made as to whether the function is busy, INQUIRY 1234. This determination is made by checking the busy indicator in the function table entry. If the function is busy, a busy condition is provided, step 1236. With the busy condition, the instruction may be retried instead of being discarded.

If the function is not busy, a further determination is made as to whether the offset specified in the instruction is valid, INQUIRY 1238. That is, the offset is combined with the length of the operation within the base address and the length of the address space as specified in the function table entry? If not, an exception condition is provided, step 1240. However, if the offset is valid, then a determination is made as to whether the length is valid, INQUIRY 1242. That is, the address space type, the offset within the address space, and the integer bound size are made length-efficient. If not, an exception condition is provided, step 1244. Otherwise, processing continues with the store instruction. (in one embodiment, the firmware performs the checks described above).

Continuing with FIG. 12B, a determination is made by firmware as to whether to store the configuration address space for the adapter function, INQUIRY 1250. That is, based on the configuration of the memory of the adapter function, is the particular address space provided in the instruction the configuration space? If so, the firmware performs various processes to provide the request to the hub coupled to the adapter function; the hub then routes the request to a function, step 1252.

For example, the firmware obtains the requestor ID from the function table entry pointed to by the function handle provided in the instruction operator. Further, based on information in the function table entry (e.g., internal routing information), the firmware determines the hub that received the request. That is, the environment may have one or more hubs, and the firmware determines the hub coupled to the adapter function. It then forwards the request to the hub. The hub generates a configuration write request packet that flows out of the PCI bus to the adapter function identified by the RID in the function table entry. The configuration write request includes a RID and an offset (i.e., data address) for storing data, as described below.

Returning to INQUIRY 1250, if the specified address space is not a configuration space, then the firmware again performs various processes to provide the request to the hub, STEP 1254. The firmware uses the handle to select a function table entry and it obtains information from the entry that locates the appropriate hub. It also calculates the data address used in the store operation. The address is calculated by adding the BAR start address obtained from the function table entry to the offset provided in the instruction. Providing the calculated data address to a hub. The hub then obtains the address and includes it in a request packet, such as a DMA write request packet, that is streamed over the PCI bus to the adapter function.

In response to receiving the request, either through step 1252 or step 1254, the adapter function stores the requested data in the specified location (i.e., at the data address), step 1256. The PCI store operation is completed with an indication of success (e.g., a condition code set to zero).

In addition to load and store instructions, which typically load or store up to, for example, 8 bytes, another instruction that can be executed is a store block instruction. The store block instruction stores a larger block of data (e.g., 16, 32, 64, 128, or 256 bytes) at a specified location of the adapter function; the block size is not necessarily limited to a size that is a power of 2. In one example, the specified location is in a memory space (not an I/O or configuration space) of the adapter function.

One embodiment of a PCI store Block instruction is described with reference to FIG. 13A. As shown, PCI store block instruction 1300 includes, for example, an opcode 1302 indicating a PCI store block instruction; a first field 804 specifying a location including various information about an adapter function to which data is stored; a second field 1306 specifying a location that includes an offset within a specified address space to which data is stored; and a third field 1308 specifying the location of a system memory address including data to be stored in the adapter function. The contents of the locations specified by fields 1, 2, and 3 are further described below.

In one example, field 1 specifies a general register that includes various information. As shown in fig. 13B, the contents of the register include, for example:

enable handle 1310: this field is the enabled function handle of the adapter function to which the data is stored;

the address space 1312: this field identifies the address space within the adapter function to which the data is stored;

length field 1314: this field specifies the length of the store operation (e.g., the number of bytes to be stored); and

status field 1316: this field provides a status code that can be used when the instruction ends with a predetermined condition code.

In one example, field 2 specifies a general purpose register, and as shown in FIG. 13C, the contents of the register include a value (e.g., a 64-bit unsigned integer) that indicates an offset within a specified address space to which the data is to be stored.

In one example, as shown in FIG. 13D, field 3 includes the logical address of the first byte of data in system memory 1322 to be stored into the adapter function.

One embodiment of the logic associated with a PCI store Block instruction is described with reference to FIGS. 14A-14B. In one example, instructions are issued by an operating system and executed by a processor (e.g., firmware) executing the operating system.

To issue an instruction, the operating system provides the instruction (e.g., in one or more registers specified by the instruction) with the following operators: a PCI function handle, PCI Address space (PCIAS), an offset in PCI Address space, a length of data to be stored, and a pointer to data to be stored. Pointer operators may include registers and signed or unsigned shifts. Upon successful completion of the PCI store Block instruction, the data is stored in the location specified by the instruction.

Referring to FIG. 14A, initially, a determination is made as to whether a facility is installed that allows PCI store block instructions, INQUIRY 1400. This determination is made, for example, by examining an indicator stored in the control block. If no tools are installed, an exception condition is provided, STEP 1402. Otherwise, if the tool is installed, a determination is made as to whether the handle provided in the operator of the PCI store Block instruction is enabled, INQUIRY 1404. In one example, this determination is made by examining an enable indicator in the handle. If the handle is not enabled, an exception condition is provided, STEP 1406.

If the handle is enabled, the handle is used to locate the function table entry, STEP 1412. That is, at least a portion of the handle is used as an index into the function table to locate the function table entry corresponding to the adapter function to which the data is stored. Thereafter, a determination is made as to whether the operating system is authorized, INQUIRY 1414. In one example, this includes verifying the region number in the FTE with the region number of the operating system that issued the instruction. If they are not equal, the operating system is not authorized. If they are equal, a further determination is made as to whether the configuration from which the instruction was issued is a guest. If so, an exception condition is provided, step 1416. If the configuration is not a customer, the query may be ignored, or other authorizations may be checked, if specified.

A determination is then made as to whether the function is enabled, INQUIRY 1418. In one example, this determination is made by checking an enable indicator in the function table entry. If it is not enabled, an exception condition is provided, step 1420.

If the function is enabled, a determination is made as to whether the address space is valid, INQUIRY 1422. E.g., whether the specified address space is the adapter function's specified address space and whether one of them is appropriate for the instruction (i.e., memory space). If the address space is not valid, an exception condition is provided, STEP 1424. Otherwise, a determination is made whether to block the load/store, INQUIRY 1426. In one example, this determination is made by checking a status indicator in the function table entry. If the load/store is blocked, then an exception condition is provided, step 1428.

However, if the load/store is not blocked, a determination is made whether recovery is active, INQUIRY 1430. In one example, this determination is made by checking a recovery initiation indicator in the function table entry. If recovery is active, then an exception condition is provided, step 1432. Otherwise, a determination is made as to whether the function is busy, INQUIRY 1434. This determination is made by checking the busy indicator in the function table entry. If the function is busy, a busy condition is provided, step 1436. With the busy condition, the instruction may be retried instead of being discarded.

If the function is not busy, a further determination is made as to whether the offset specified in the instruction is valid, INQUIRY 1438. That is, the offset is combined with the length of the operation within the base address and the length of the address space specified in the function table entry? If not, an exception condition is provided, step 1440. However, if the offset is valid, then a determination is made as to whether the length is valid, INQUIRY 1442. That is, the address space type, the offset within the address space, and the integer bound size are made length-efficient. If not, an exception condition is provided, step 1444. Otherwise, processing continues with the store instruction. (in one embodiment, the firmware performs the checks described above).

Continuing with FIG. 14B, a determination is made by the firmware as to whether memory including data to be stored is accessible, INQUIRY 1450. If not, an exception condition is provided, step 1452. If so, the firmware performs various processes to provide the request to the hub coupled to the adapter function; the hub then routes the request to a function, step 1454.

For example, the firmware uses the handle to select a function table entry and it passes the entry to obtain information to locate the appropriate hub. It also calculates the data address to be used in the memory block operation. The address is calculated by adding the BAR start address obtained from the function table entry (with the BAR identified by the address space identifier) to the offset provided in the instruction. Providing the calculated data address to a hub. In addition, data referenced by the address provided in the instruction is retrieved from system memory and provided to the I/O hub. The hub then obtains the address and includes it in a request packet, such as a DMA write request packet, that is streamed over the PCI bus to the adapter function.

In response to receiving the request, the adapter function stores the requested data in the specified location (i.e., at the data address), step 1456. The PCI store block operation is completed with an indication of success (e.g., a condition code set to zero).

Described in detail above is the ability to control access to particular adapter functions through configuration. Each adapter function has a function table entry associated with it and each adapter function located within a function table entry is an indication of what configuration (e.g., operating system, logical partition, guest, etc.) is allowed to access the adapter function corresponding to the entry. The above is determined by a reconfigurable policy. When the configuration issues instructions to the adapter function, the policy is enforced by the firmware. When the adapter function is under control of privileged firmware (e.g., in recovery), the instruction execution is modified. When the adapter is performing system maintenance or is for other specified reasons, access is blocked.

Direct access adapters are provided and configurations that do not require the use of separate I/O partitions are not required. Provides strict isolation between partitions and provides very low latency access to adapters. No communication between partitions is required in order to control access to the adapter. It provides control without using page tables for adapter specific instructions.

In the embodiment described herein, the adapter is a PCI adapter. As used herein, PCI refers to any adapter implemented according to a PCI-based specification defined by the peripheral component interconnect special interest group (PCI-SIG), including but not limited to PCI or PCIe. In one particular example, peripheral component interconnect express (PCIe) is a component-level interconnect standard that defines a bi-directional communication protocol for transactions between an I/O adapter and a host system. According to the PCIe standard for transmission over a PCIe bus, PCIe communications are encapsulated in packets. Transactions originating at the I/O adapter and terminating at the host system are referred to as upbound transactions. Transactions originating at the host system and terminating at the I/O adapter are referred to as downstream transactions. The PCIe topology is based on point-to-point unidirectional links that are paired (e.g., one uplink, one downlink) to form a PCIe bus. The PCIe standard is maintained and published by the PCI-SIG.

As will be appreciated by one skilled in the art, the present invention may be embodied as a system, method or computer program product. Accordingly, the present disclosure may be embodied in the form of: may be embodied entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in a combination of hardware and software, and may be referred to herein generally as a "circuit," module "or" system. Furthermore, in some embodiments, the invention may also be embodied in the form of a computer program product in one or more computer-readable media having computer-readable program code embodied in the medium.

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

Referring now to FIG. 15, in one example, a computer program product 1500 includes, for instance, one or more computer-readable storage media 1502 having computer-readable program code means or logic 1504 stored thereon to provide and facilitate one or more aspects of the present invention.

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

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute 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 case of a remote computer, 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 (for example, through the Internet using an Internet service provider).

The present invention is 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 program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means (instructions) which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations 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 diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition to the foregoing, one or more aspects of the present invention may be provided, offered, deployed, managed, serviced, etc. by a service provider who offers management of a user's environment. For example, a service provider can create, maintain, support, etc., computer code and/or computer infrastructure that performs one or more aspects of the present invention for one or more users. The service provider, in turn, may accept payment from the user, for example, according to a subscription and/or fee agreement. Additionally or alternatively, the service provider may receive payment from the sale of advertising content to one or more third parties.

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

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

As yet another aspect of the present invention, a process for integrating computing infrastructure comprising integrating computer readable code into a computer system may be provided. The computer system includes a computer-readable medium, wherein the computer medium includes one or more aspects of the present invention. The code in combination with the computer system is capable of performing one or more aspects of the present invention.

While various embodiments are described above, these are only examples. For example, computing environments of other architectures may incorporate and use one or more aspects of the present invention. By way of example, except SystemServers other than servers, such as Power systems servers or other servers offered by International Business machines corporation, or servers of other companies, may include, use and/or benefit from one or more aspects of the present invention. Moreover, although in the examples illustrated herein, the adapters and PCI hubs are considered to be part of the server, in other embodiments, they need not be considered to be part of the server, but may simply be considered to be coupled to the system memory and/or other components of the computing environment. The computing environment need not be a server. Moreover, although the adapters are PCI based, one or more aspects of the present invention may be used with other adapters or other I/O components. Adapters and PCI adapters are examples only. Moreover, more, less, or different information may be included in the function table entry, the device table entry, and/or the function handle without departing from the scope of the present invention. Further, while tables are described, any data structure may be used and the term table includes all such data structures. Still further, other instructions may be controlled by one or more aspects of the present invention. Many other variations are possible.

Moreover, other types of computing environments may benefit from one or more aspects of the present invention. By way of example, a data processing system suitable for storing and/or executing program code will be used that includes at least two processors coupled directly or indirectly to memory elements through a system bus. The memory elements include, for instance, local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

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

Referring to FIG. 16, representative components of a host computer system 5000 to implement one or more aspects of the present invention are depicted. Representative host computer 5000 includes one or more CPUs in communication with computer memory (i.e., central storage) 5002, as well as I/O interfaces to storage media devices 5011 and networks 5010 for communicating with other computers or SANs and the like. The CPU5001 conforms to an architecture having an architectural instruction set and architectural functions. The CPU5001 may have Dynamic Address Translation (DAT) 5003 for translating program addresses (virtual addresses) to real addresses of memory. A DAT typically includes a Translation Lookaside Buffer (TLB) 5007 for caching translations so that later accesses to a block of computer memory 5002 do not require the delay of address translation. Typically, a cache 5009 is used between the computer memory 5002 and the processor 5001. The cache 5009 may be hierarchical, having a large cache available to more than one CPU, and smaller, faster (lower level) caches between the large cache and each CPU. In some embodiments, the lower level cache is split to provide separate lower level caches for instruction fetching and data accesses. In one embodiment, instructions are fetched from memory 5002 by instruction fetch unit 5004 via cache 5009. The instructions are decoded in the instruction decode unit 5006 and (in some embodiments, with other instructions) sent to the one or more instruction execution units 5008. Typically, several execution units 5008 are used, such as an arithmetic execution unit, a floating point execution unit, and a branch instruction execution unit. The specification is executed by the execution unit, accessing operands from registers or memory specified by the instruction, as needed. If an operand is to be accessed (loaded or stored) from memory 5002, load/store unit 5005 typically handles the access under the control of the instruction being executed. The instructions may be executed in hardware circuitry, or in internal microcode (firmware), or in a combination thereof.

Note that the computer system includes information in local (or main) memory, as well as addressing, protection, and reference and change records. Some aspects of addressing include address format, concept of address space, various types of addresses, and the manner in which one type of address is translated to another type of address. Some main memories include persistently allocated memory locations. The main memory provides the system with fast-access data storage that is directly addressable. Both data and programs will be loaded into main memory (from the input device) before they can be processed.

The main memory may include one or more smaller, faster-access cache memories, sometimes referred to as caches. The cache is typically physically associated with the CPU or I/O processor. The effects of the physical structure and use of different storage media are not typically observed by a program except in terms of performance.

Separate caches for instruction and data operands may be maintained. Information in a cache may be maintained as contiguous bytes on integer boundaries called cache blocks or cache lines (or simply lines). The model may provide an extract cache attribute instruction that returns the byte size of the cache line. The model may also provide PREFETCHDATA (prefetch data) and prefetch data relative issue (prefetch longer data) instructions that enable a prefetch to be stored into the data or instruction cache, or a release of data from the cache.

The memory is considered to be a long horizontal string of bits. For most operations, accesses to memory are made in left-to-right order. The bit string is subdivided into units of eight bits. The eight-bit unit is called a byte, which is the basic building block for all information formats. Each byte location in memory is identified by a unique non-negative integer, which is the address of the byte location, or simply, the byte address. Adjacent byte positions have consecutive addresses, starting at 0 on the left and proceeding in left to right order. The address is an unsigned binary integer and is 24, 31 or 64 bits.

Information is transferred between the memory and the CPU or channel subsystem one byte or a group of bytes at a time. Unless otherwise specified, e.g. inA group of bytes in memory is addressed by the leftmost byte of the group. The number of bytes in a group may be implied or explicitly specified by the operation to be performed. When used in CPU operations, a group of bytes is called a field. Within each group of bytes, e.g. inIn which bits are numbered in left-to-right order. In thatIn (d), the leftmost bit is sometimes referred to as the "high order" bit and the rightmost bit is referred to as the "low order" bit. However, the number of bits is not a memory address. Only bytes can be addressed. To operate on a single bit of a byte in memory, the entire byte is accessed. The bits on a byte are numbered 0 to 7 from left to right (e.g., inIn (1). Bits in the address are numbered 8-31 or 40-63 for a 24-bit address, or 1-31 or 33-63 for a 31-bit address; they are numbered 0-63 for a 64-bit address. In any other fixed length format of a plurality of bytes, the bits that make up the format are numbered consecutively starting from 0. For error detection, and preferably for correction, one or more check bits may be passed with each byte or group of bytes. Such check bits are automatically generated by the machine and cannot be directly controlled by the program. The storage capacity is expressed in number of bytes. When the length of a memory operand field is implied by the opcode of the instruction, the field is said to have a fixed length, which may be one, two, four, eight, or sixteen bytes. Larger fields may be implied for certain instructions. When the length of the memory operand field is not implied but explicitly indicated, the field is said to have a variable length. Variable length operands may be variable in length in increments of one byte (or for some instructions, in multiples of two bytes or other multiples). When information is placed in memory, only the contents of which byte locations included in the specified field are replaced, even though the width of the physical path to memory may be greater than the length of the field being stored.

Some units of information are located on integer limits in memory. For a unit of information, a bound is said to be an integer when its memory address is a multiple of the length of the unit in bytes. Special names are given to the fields of 2, 4, 6, 8 and 16 bytes on the integer limit. A halfword is a set of two consecutive bytes on a two-byte boundary and is the basic building block of instructions. A word is a set of four consecutive bytes on a four-byte boundary. A doubleword is a set of eight consecutive bytes on an eight-byte boundary. A quad word (quadword) is a set of 16 contiguous bytes on a 16-byte boundary. When a memory address specifies a halfword, a word, a doubleword, and a quadword, the binary representation of the address includes one, two, three, or four rightmost zero bits, respectively. The instruction will be on a two-byte integer boundary. Most instructions have memory operands that do not have boundary alignment requirements.

On devices that implement separate caches for instructions and data operands, significant delays may be experienced if a program stores in a cache line and an instruction is subsequently fetched from the cache line, regardless of whether the store alters the subsequently fetched instruction.

In one embodiment, the invention may be implemented by software (sometimes referred to as licensed internal code, firmware, microcode, millicode, picocode, etc., any of which would be consistent with the invention). Referring to fig. 16, software program code embodying the present invention is typically accessible by a processor of the host system 5000 from a long term storage media device 5011, such as a CD-ROM drive, tape drive or hard drive. The software program code may be embodied on any of a variety of known media for use with a data processing system, such as a floppy disk, a hard drive, or a CD-ROM. The code may be distributed on such media, or may be distributed to users of other computer systems from the computer memory 5002 or storage devices of one computer system over the network 5010 for use by users of such other systems.

The software program code includes an operating system which controls the function and interaction of the various computer components and one or more application programs. The program code is typically paged from the storage media device 5011 to the relatively higher speed computer memory 5002 where it is available to the processor 5001. The techniques and methods for embodying software program code in memory, on physical media, and/or distributing software code via networks are well known and will not be discussed further herein. When the program code is created and stored on a tangible medium, including but not limited to an electronic memory module (RAM), flash memory, Compact Discs (CDs), DVDs, tapes, etc., it is often referred to as a "computer program product". The computer program product medium is typically readable by processing circuitry preferably located in a computer system for execution by the processing circuitry.

FIG. 17 illustrates a representative workstation or server hardware system in which the present invention may be implemented. The system 5020 of fig. 17 includes a representative base computer system (base computer) 5021, such as a personal computer, workstation or server, including optional peripherals. A basic computer system 5021 comprises one or more processors 5026 and a bus used to connect and enable communication between the processors 5026 and other components of the system 5021, in accordance with known techniques. The bus connects the processor 5026 to memory 5025 and long-term storage 5027 which may comprise a hard disk drive (including any of magnetic media, CD, DVD, and flash memory, for example) or a tape drive, for example. The system 5021 may also include a user interface adapter that connects the microprocessor 5026 via the bus to one or more interface devices, such as a keyboard 5024, a mouse 5023, a printer/scanner 5030, and/or other interface devices, which may be any user interface device such as a touch-sensitive screen, a digital input pad (digizzedentrypad), etc. The bus may also connect a display device 5022, such as an LCD screen or monitor, to the microprocessor 5026 via a display adapter.

The system 5021 may communicate with other computers or networks of computers via a network adapter capable of communicating 5028 with a network 5029. Exemplary network adapters are communications channels, token ring, Ethernet or modems. Alternatively, the system 5021 may communicate using a wireless interface, such as a CDPD (cellular digital packet data) card. The system 5021 can be associated with such other computers in a Local Area Network (LAN) or a Wide Area Network (WAN), or the system 5021 can be a client in a client/server arrangement with another computer, etc. All of these configurations, as well as suitable communication hardware and software, are known in the art.

Figure 18 illustrates a data processing network 5040 in which the present invention may be implemented. The data processing network 5040 may include a plurality of separate networks, such as wireless and wired networks, each of which may include a plurality of separate workstations 5041, 5042, 5043, 5044. Further, those skilled in the art will appreciate that one or more LANs may be included, wherein a LAN may include a plurality of intelligent workstations coupled to a host processor.

Still referring to FIG. 18, the network may also include mainframe computers or servers, such as a gateway computer (client server 5046) or application server (remote server 5048, which may access a data repository and may also be accessed directly from a workstation 5045). The gateway computer 5046 serves as a point of entry into each individual network. When connecting one networking protocol to another, a gateway is required. The gateway 5046 may preferably be coupled to another network (e.g., the internet 5047) by a communications link. The gateway 5046 may also be directly coupled to one or more workstations 5041, 5042, 5043, 5044 using a communications link. IBMeServer available from International Business machines corporation may be utilized^TMThe server implements a gateway computer.

Referring concurrently to fig. 17 and 18, software programming code which may embody the present invention may be accessed by the processor 5026 of the system 5020 from long-term storage media 5027, such as a CD-ROM drive or hard drive. The software programming code may be embodied on any of a variety of known media for use with a data processing system, such as a floppy disk, a hard drive, or a CD-ROM. The code may be distributed on such media, or from the memory or storage of one computer system over a network to users 5050, 5051 of other computer systems for use by users of such other systems.

Alternatively, the programming code may be embodied in the memory 5025 and accessed by the processor 5026 using a processor bus. Such programming code includes an operating system which controls the function and interaction of the various computer components and one or more application programs 5032. Program code is typically paged from the storage medium 5027 to high-speed memory 5025 where it is available for processing by the processor 5026. Techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be discussed further herein. Program code, when created and stored on tangible media, including but not limited to electronic memory modules (RAM), flash memory, Compact Discs (CDs), DVDs, tapes, etc., is commonly referred to as a "computer program product". The computer program product medium is typically readable by a processing circuit, preferably located in a computer system, for execution by the processing circuit.

The cache most readily used by the processor (which is typically faster and smaller than the other caches of the processor) is the lowest level (L1 or level 1) cache, and main storage (main memory) is the highest level cache (L3 if there are three levels). The lowest level cache is often divided into an instruction cache (I-cache) that holds the machine instructions to be executed, and a data cache (D-cache) that holds the data operands.

Referring to FIG. 19, an exemplary processor embodiment is shown for the processor 5026. Typically, one or more levels of cache 5053 are used to buffer memory blocks in order to improve processor performance. The cache 5053 is a cache buffer that holds cache lines of memory data that are likely to be used. Typical cache lines are 64, 128 or 256 bytes of memory data. A separate cache is typically used for caching instructions rather than data. Cache coherency (synchronization of copies of lines in memory and cache) is typically provided by various "snoop" algorithms well known in the art. The main memory 5025 of the processor system is commonly referred to as a cache. In a processor system having 4 levels of cache 5053, main memory 5025 is sometimes referred to as a level 5 (L5) cache, because it is typically faster and maintains only a portion of the non-volatile storage (DASD, tape, etc.) that is available to the computer system. Main memory 5025 may "cache" pages of data paged in and out of main memory 5025 by the operating system.

Program counter (instruction counter) 5061 keeps track of the address of the current instruction to be executed.The program counter in the processor is 64 bits and may be truncated to 31 or 24 bits to support the previous addressing limits. The program counter is typically embodied in the computer's PSW (program status word) so that it persists during context transitions. Thus, an in-progress program having a program counter value may be interrupted by, for example, an operating system (context switch from a program environment to an operating system environment). When a program is inactive, the PSW of the program maintains a program counter value, and while the operating system executes, the program counter (in the PSW) of the operating system is used. Typically, the program counter is incremented by an amount equal to the number of bytes of the current instruction. RISC (reduced instruction set computing) instructions are typically of fixed length, while CISC (Complex instruction set computing) instructions are typically of variable length.Is a CISC instruction having a length of 2, 4 or 6 bytes. Program counter 5061 is modified by, for example, a context switch operation or a branch taken operation of a branch instruction. In a context switch operation, the current program counter value is saved in a program status word along with other status information about the program being executed (such as condition codes), and a new program counter value is loaded and points to the instruction of the new program module to be executed. A branch taken operation is performed to allow the program to make a decision or loop within the program by loading the result of the branch instruction into the program counter 5061.

Typically, instructions are fetched on behalf of the processor 5026 using an instruction fetch unit 5055. The fetch unit may fetch a "next sequence of instructions," a target instruction of a branch taken instruction, or a first instruction of a context-switched program. Present instruction fetch units typically use prefetch techniques to speculatively prefetch instructions based on the likelihood that the prefetched instructions will be used. For example, the fetch unit may fetch 16 bytes of instructions, including the next sequential instruction and additional bytes of further sequential instructions.

The fetched instructions are then executed by the processor 5026. In one embodiment, the fetched instructions are passed to the dispatch unit 5056 of the fetch unit. The dispatch unit decodes the instructions and forwards information about the decoded instructions to the appropriate units 5057, 5058, 5060. The execution unit 5057 will typically receive information from the instruction fetch unit 5055 regarding decoded arithmetic instructions, and will perform arithmetic operations on operands according to the opcode of the instruction. Operands are preferably provided to the execution unit 5057 from storage 5025, architectural registers 5059, or from an immediate field (immediatefield) of the instruction being executed. The results of the execution, when stored, are stored in storage 5025, registers 5059, or other machine hardware (such as control registers, PSW registers, etc.).

The processor 5026 typically has one or more units 5057, 5058, 5060 for performing the function of instructions. Referring to fig. 20A, an execution unit 5057 may communicate with architected general registers 5059, decode/dispatch unit 5056, load store unit 5060, and other 5065 processor units via interface logic 5071. The execution unit 5057 may use several register circuits 5067, 5068, 5069 to hold information that the Arithmetic Logic Unit (ALU) 5066 is to operate on. The ALU performs arithmetic operations such as add, subtract, multiply, divide, and logical operations such as AND, OR, and exclusive OR (XOR), rotate, and shift. Preferably, the ALU supports specialized operations that are design dependent. Other circuitry may provide other architectural tools 5072, including condition codes and recovery support logic, for example. Typically, the results of the ALU operations are held in output register circuitry 5070, which may forward the results to a variety of other processing functions. There are many processor unit arrangements and this description is intended only to provide a representative understanding of one embodiment.

For example, ADD instructions will be executed in an execution unit 5057 having arithmetic and logical functionality, while floating point instructions will be executed in floating point execution with dedicated floating point capabilities, for example. Preferably, the execution unit operates on the operands identified by the instruction by executing the function defined by the opcode on the operands. For example, an ADD instruction may be executed by the execution unit 5057 on operands found in two registers 5059 identified by register fields of the instruction.

The execution unit 5057 performs arithmetic addition on two operands and stores the result in a third operand, which may be a third register or one of the two source registers. The execution unit preferably utilizes an Arithmetic Logic Unit (ALU) 5066, which can perform a variety of logic functions, such as shifting, rotating, and, OR, and XOR, as well as any of a variety of algebraic functions, including addition, subtraction, multiplication, and division. Some ALUs 5056 are designed for scalar operations, and some for floating point. Depending on the architecture, the data may be big endian (where the least significant byte is located at the most significant byte address) or little endian (where the least significant byte is located at the least significant byte address). IBMIs the large end. Depending on the architecture, the signed field may be sign and magnitude, 1's complement, or 2's complement. A 2's complement number is advantageous in that the ALU does not need to design subtraction capability because only addition in the ALU is required, whether negative or positive in the 2's complement. The numbers are typically described in shorthand, where a 12-bit field defines the address of a block of 4096 bytes, and are typically described as a 4Kbyte block, for example.

Referring to FIG. 20B, branch instruction information for executing a branch instruction is typically sent to a branch unit 5058, which often predicts branch outcome before other conditional operations are completed, using a branch prediction algorithm such as branch history table 5082. Before the conditional operation completes, the target of the current branch instruction will be fetched and speculatively executed. When the conditional operation completes, the speculatively executed branch instruction is either completed or discarded based on the condition of the conditional operation and the speculative result. Typical branch instructions may test the condition code and branch to a target address if the condition code satisfies the branch requirement of the branch instruction, the branch address may be calculated based on a number including, for example, a number found in a register field or an immediate field of the instruction. The branch unit 5058 may utilize an ALU5074 having a plurality of input register circuits 5075, 5076, 5077 and an output register circuit 5080. The branch unit 5058 may communicate with, for example, general registers 5059, decode dispatch unit 5056, or other circuitry 5073.

Execution of a set of instructions may be interrupted for a number of reasons including, for example, a context switch initiated by the operating system, a program exception or error causing a context switch, an I/O interrupt signal causing a context switch, or multi-threaded activity of multiple programs (in a multi-threaded environment). Preferably, the context switch action saves state information about the currently executing program and then loads state information about another program being invoked. The state information may be stored, for example, in hardware registers or memory. The state information preferably includes a program counter value pointing to the next instruction to be executed, condition codes, memory translation information and architectural register contents. The context translation activities may be implemented by hardware circuitry, application programs, operating system programs, or firmware code (microcode, pico code, or Licensed Internal Code (LIC)), alone or in combination.

The processor accesses operands according to the instruction defined method. An instruction may provide an immediate operand using the value of a portion of the instruction, may provide one or more register fields that explicitly point to general purpose registers or special purpose registers (e.g., floating point registers). The instruction may utilize the implied register determined by the opcode field as an operand. The instruction may utilize memory locations for operands. The memory location of the operand may be provided by a register, an immediate field, or a combination of a register and an immediate field, such asIllustrated by the long displacement facility (facility), where the instruction defines a base register, an index register, and an immediate field (displacement field) that are added together to provide, for example, the address of an operand in memory. Location here typically means a location in main memory (main storage device) unless otherwise specified.

Referring to fig. 20C, a processor accesses a memory using a load/store unit 5060. The load/store unit 5060 may perform a load operation by obtaining the address of a target operand in memory 5053 and loading the operand into a register 5059 or other memory 5053 location, or may perform a store operation by obtaining the address of a target operand in memory 5053 and storing data obtained from a register 5059 or another memory 5053 location in the target operand location in memory 5053. The load/store unit 5060 may be speculative and may access memory in an out-of-order relative to instruction order, but the load/store unit 5060 will maintain the appearance to a program that instructions are executed in order. The load/store unit 5060 may communicate with general registers 5059, decryption/dispatch unit 5056, cache/memory interface 5053 or other elements 5083, and includes various register circuits, ALUs 5080 and control logic 5085 to calculate memory addresses and provide pipeline order to keep operations in order. Some operations may be out of order, but the load/store unit provides functionality such that operations that are performed out of order appear to the program as if they were performed in order, as is well known in the art.

Preferably, the addresses that are "seen" by the application are commonly referred to as virtual addresses. Virtual addresses are sometimes referred to as "logical addresses" and "effective addresses". These virtual addresses are virtual in that they are redirected to a physical memory location by one of a variety of Dynamic Address Translation (DAT) techniques including, but not limited to, simply prefixing the virtual address with an offset value, translating the virtual address via one or more translation tables, preferably including at least a segment table and a page table (either individually or in combination), preferably the segment table having an entry pointing to the page table. In thatA translation hierarchy is provided that includes a region first table, a region second table, a region third table, a segment table, and an optional page table. The performance of translation tables is typically improved by utilizing a Translation Lookaside Buffer (TLB) that includes entries that map virtual addresses to associated physical memory locations. When a DAT translates a virtual address using a translation table, an entry is created. Subsequent use of the virtual address may then utilize the entry of the fast TLB, rather than the slow sequential translation table access. TLB content may be managed by a plurality of replacement algorithms including LRU (least recently used).

Where the processors are processors of a multi-processor system, each processor has the responsibility of maintaining shared resources, such as I/O, caches, TLBs, and memory, which are interlocked to achieve coherency. Typically, "snooping" techniques will be used to maintain cache coherency. In a snooping environment, each cache line may be marked as being in one of a shared state, an exclusive state, a changed state, an invalid state, etc., to facilitate sharing.

An I/O unit 5054 (fig. 19) provides the processor with means for attaching to peripheral devices including, for example, tapes, disks, printers, displays, and networks. The I/O cells are typically presented to the computer program by a software driver. In a location such as fromIs/are as followsThe channel adapter and the open system adapter are I/O units of the mainframe computer that provide communication between the operating system and peripheral devices.

Moreover, other types of computing environments may benefit from one or more aspects of the present invention. By way of example, an environment may include an emulator (e.g., software or other emulation mechanisms), in which a particular architecture (including, for example, instruction execution, architectural functions such as address translation, and architectural registers) or a subset thereof is emulated (e.g., in a native computer system having a processor and memory). In such an environment, one or more emulation functions of the emulator can implement one or more aspects of the present invention, even though the computer executing the emulator may have a different architecture than the capabilities being emulated. As one example, in emulation mode, a particular instruction or operation being emulated is decoded, and the appropriate emulation function is established to implement the single instruction or operation.

In an emulation environment, a host computer includes, for example, memory to store instructions and data; an instruction fetch unit to fetch instructions from memory and, optionally, to provide local buffering of fetched instructions; an instruction decode unit to receive the fetched instruction and determine a type of instruction that has been fetched; and an instruction execution unit to execute the instruction. Execution may include loading data from memory to a register; storing data from the register back to the memory; or perform some type of arithmetic or logical operation as determined by the decode unit. In one example, each unit is implemented in software. For example, the operations performed by the units are implemented as one or more subroutines in emulator software.

More specifically, in a mainframe computer, programmers (typically today's "C" programmers) typically use architected machine instructions through compiler applications. The instructions stored in the storage medium may be inEither locally in a server or in a machine executing other architectures. They may be present and futureMainframe computer server andother machines (e.g., Power systems servers andserver) is simulated. They can be used byAMD^TMEtc. are executed in machines running Linux on various machines of manufactured hardware. Except that atWith this hardware on execution, Linux can also be used for machines that use emulation provided by TurboHercules (www.turbohercules.com /), Hercules (www.hercules-390. org /) or FSI (fundamentals software, Inc) (www.funsoft.com /), where execution is typically in emulation mode. In emulation mode, emulation software is executed by the native processor to emulate the architecture of the emulated processor.

The native processor typically executes emulation software, which includes firmware or a native operating system, to execute an emulation program of the emulated processor. The emulation software is responsible for fetching and executing instructions of the emulated processor architecture. The emulation software maintains an emulated program counter to keep track of instruction boundaries. The emulation software can fetch one or more emulated machine instructions at a time and convert the one or more emulated machine instructions into a corresponding set of native machine instructions for execution by the native processor. These translated instructions may be cached so that faster translations may be accomplished. Nevertheless, the emulation software will maintain the architectural rules of the emulated processor architecture to ensure that the operating system and applications written for the emulated processor operate correctly. Furthermore, the emulation software will provide resources determined by the emulated processor architecture, including but not limited to control registers, general purpose registers, floating point registers, dynamic address translation functions including, for example, segment and page tables, interrupt mechanisms, context translation mechanisms, time of day (TOD) clocks, and architectural interfaces to the I/O subsystem, such that operating systems or applications designed to run on the emulated processor may run on the native processor with the emulation software.

The particular instruction being emulated is decoded and a subroutine is called to perform the function of that single instruction. The emulation software functions that emulate the functions of an emulated processor are implemented, for example, in a "C" subroutine or driver, or by other methods that provide drivers for specific hardware, as will be understood by those skilled in the art after understanding the description of the preferred embodiments. Including, but not limited to, U.S. patent No. 5,551,013 entitled "multiprocessor hardware emulation" to beaussoleil et al; and U.S. patent certificate number 6,009,261 entitled "preprocessing of storettaggetoutputting for simulating incorporated PatibelteIndustmeasuring A TargetProcesser" to Scalazi et al; and U.S. patent document No. 5,574,873 entitled "decodingguest instruments directive access instruments" by Davidian et al; and U.S. patent certificate number 6,308,255 entitled "symmetry multi processing and chip set used for a processsor support alloy non-native codex runinasystem" by Gorishek et al; and U.S. patent document No. 6,463,582 entitled "dynamic Optimizing ObjectCode Translationmethod for implementing and dynamic Optimizing ObjectCode Translationmethod" to Lethin et al; and U.S. patent certificate number 5,790,825 entitled "method for simulating Guest Instructions Structure of HostComputerThrough dynamic Recompatibilities of HostInstructions" by EricTraut; as well as numerous other patents, show various known ways to implement emulation of instruction formats architected for different machines for a target machine available to those skilled in the art.

In fig. 21, an example of an emulated host computer system 5092 is provided that emulates a host computer system 5000' of a host architecture. In the emulated host computer system 5092, the host processor (CPU) 5091 is an emulated host processor (or virtual host processor) and includes an emulated processor 5093 having a different native instruction set architecture than the processor 5091 of the host computer 5000'. The emulation host computer system 5092 has a memory 5094 accessible by an emulation processor 5093. In the exemplary embodiment, memory 5094 is partitioned into a host computer memory 5096 portion and an emulation routines 5097 portion. Host computer memory 5096 is available to programs emulating host computer 5092, according to the host computer architecture. The emulation processor 5093 executes native instructions of an architected instruction set of a different architecture than the emulated processor 5091 (i.e., native instructions from the emulated program processor 5097), and may access host instructions for execution from programs in the host computer memory 5096 by using one or more instructions obtained from a sequence and access/decode routine that may decode the accessed host instructions to determine a native instruction execution routine for emulating the function of the accessed host instructions. Other tools defined for the host computer system 5000' architecture may be emulated by the architecture tool routines, including such tools as general purpose registers, control registers, dynamic address translation and I/O subsystem support and processor caches. The emulation routine may also take advantage of the functionality available in the emulation processor 5093 (such as dynamic translation of general purpose registers and virtual addresses) to improve the performance of the emulation routine. Specialized hardware and offload engines may also be provided to assist the processor 5093 in emulating the functionality of the host computer 5000'.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. 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. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, and/or components.

The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims (15)

1. A method of controlling access to adapters in a computing environment, the method comprising:

executing an instruction issued by an operating system to request access to an adapter, the adapter identified by a function handle providing the request, the executing comprising:

selecting a function table entry for the adapter identified by the function handle using the function handle, the function table entry including information associated with the adapter including information for determining whether the operating system is authorized to access the adapter;

determining whether to allow the operating system to access the adapter based on information in the function table entry; and

in response to determining to allow the operating system to access the adapter, allowing access to the adapter;

wherein the determining comprises comparing the region number in the function table entry with the region number in the operating system, wherein

In response to the comparison indicating inequality, disallowing the operating system access;

in response to the comparison indicating equality, determining whether to block access for a different reason;

wherein the access is allowed in response to determining that the access is not blocked for a different reason.

2. The method of claim 1, wherein the operating system comprises a guest, and wherein the comparing the area number in the function table entry to the area number in the operating system comprises checking the function table entry for an identifier of the guest, wherein the guest is allowed access in response to the identifier being in the function table entry.

3. The method of claim 1, wherein the determining whether to block access for a different reason further comprises: determining whether access is blocked for one or more reasons other than permission checking, the determining using state information of the function table entry, wherein access is allowed in response to determining not to block.

4. The method of claim 3, wherein it is determined to prevent access, and the method further comprises:

deciding whether to temporarily block access; and

in response to determining to temporarily block access, a busy indicator is provided to the operating system.

5. The method of claim 4, wherein the method further comprises: access is denied in response to a decision to block access but not temporarily.

6. The method of claim 1, wherein the method further comprises:

determining a plurality of adapters available to the computing environment; and

a function table entry is created for each of the adapters.

7. The method of claim 6, wherein the method further comprises:

determining which of the plurality of adapters are accessible to the operating system; and

indicating in the function table entry of each adapter that operating system information associated with the operating system is accessible.

8. The method of claim 7, wherein the determining which adapters the operating system has access to is based on a policy, the policy being reconfigurable.

9. The method of claim 1, wherein the request is via an instruction that is based on an architecture of the adapter.

10. A computer system for controlling access to adapters in a computing environment, the computer system comprising:

apparatus for executing an instruction issued by an operating system requesting access to an adapter, the adapter identified by a function handle provided with the request, the apparatus comprising:

means for selecting a function table entry for the adapter identified by the function handle using the function handle, the function table entry comprising information associated with the adapter including information for determining whether the operating system is authorized to access the adapter;

means for determining whether to allow the operating system to access the adapter based on information in the function table entry; and

means for, in response to determining to allow the operating system to access the adapter, allowing access to the adapter;

wherein the means for determining whether to allow the operating system to access the adapter based on the information in the function table entry comprises means for comparing a region number in the function table entry to a region number of the operating system, wherein

In response to the comparison indicating inequality, disallowing the operating system access;

in response to the comparison indicating equality, determining whether to block access for a different reason;

wherein the access is allowed in response to determining that the access is not blocked for a different reason.

11. The computer system of claim 10, wherein the operating system includes a guest, and wherein the means for comparing the area number in the function table entry to the area number in the operating system includes means for checking the function table entry for an identifier of the guest, wherein the guest is allowed access in response to the identifier being in the function table entry.

12. The computer system of claim 10, wherein the means for determining whether to block access for a different reason further comprises means for determining whether to block access for one or more reasons other than permission checking, the means for determining whether to allow the operating system access to the adapter based on information in the function table entry uses state information of the function table entry, wherein access is allowed in response to determining not to block.

13. The computer system of claim 12, wherein access is determined to be blocked, and the system further comprises:

means for deciding whether to temporarily block access; and

means for providing a busy indicator to the operating system in response to determining to temporarily block access.

14. The computer system of claim 10, wherein the system further comprises:

means for determining a plurality of adapters available to the computing environment;

means for creating a function table entry for each of the adapters;

means for determining which of the plurality of adapters are accessible to the operating system; and

means for indicating in the function table entry of each adapter that operating system information associated with the operating system is accessible.

15. The computer system of claim 13, wherein the determining which adapters the operating system has access to is based on a policy, the policy being reconfigurable.