TW201102805A - Hypervisor-based facility for communicating between a hardware management console and a logical partition - Google Patents

Abstract

A hypervisor-based facility is provided for communicating between a hardware management console (HMC) and a logical partition of a data processing system. The facility includes: packaging a request or response of a source endpoint as cargo in a generic transport primitive, the source endpoint being either an HMC or a logical partition of the data processing system; and forwarding the generic transport primitive from the source endpoint to a target endpoint via the hypervisor. The forwarding includes receiving the transport primitive at the hypervisor and forwarding the cargo of the transport primitive to the target endpoint. The cargo includes the request or response from the source endpoint, and the hypervisor forwards the cargo absent inspection or parsing of that cargo. The target endpoint is the other one of the logical partition or the hardware management console of the data processing system.

Description

201102805 VI. Description of the Invention: [Technical Field of the Invention] The present invention relates generally to a data processing system, and more particularly to a hardware management console for a system-based processing system. A hypervisor-based universal communication facility between the logical partitions and the logical partitions. * This application claims the benefit of U.S. Provisional Application No. 61/59,492, filed on Jun. 6, 2008. The entire contents of this application are incorporated herein by reference. [Prior Art] In the fourth (four) side of the complex computer system resources (four) - newly developed as a logical division of system resources. Conceptually, logical segmentation means establishing multiple discrete partitions' and assigning certain types of system resources to individual partitions. For example, 'by assigning different processors to different partitions, by sharing processors between some partitions (but not others), by specifying for each: using: group processor each partition The processor resources of the multiprocessor system are partitioned by the processing resource metrics 1 and so on available for the zone. Tasks performed within a logical partition may only use resources assigned to one partition rather than resources assigned to another partition. Generally, 'logical segmentation is enforced by a segmentation manager that is embodied as a low-level warp-horse executable instruction and data, although there may be a certain amount of hardware support for logical segmentation (such as the preservation of state information). : Body register). Low level code functions and/or hardware block access to resources allocated to different partitions. In general, one of the logical partition managers 146527.doc 201102805 includes a user interface for managing low-level code functions that enforce logical partitioning. This logical split manager interface is intended for use by a single or a small group of authorized users (i.e., system administrators). When used in this article, this low-level logical split code is called a hypervisor, and the split manager interface is called the Hardware Management Console (HMC). Communication between the HMC and the logical partition of the data processing system for (example >) simultaneous hardware maintenance, dynamic logic partitioning, inventory collection (invent〇ry c〇Uecti〇n), virtual input/output (I/O) ) Device mapping and the like may be desirable. A communication method between the HMC and the logical partition of the data processing system utilizes resource monitoring for communication between the HMC and high-intensity computing architecture platform requirements (pApR) (ie, AIX® partition and LINUX partition) And control (RMC) based facilities. (ΑΙχ® is a registered trademark of International Business Machines Corporation, Annonk, New York, Usa.) Other names used herein may be registered trademarks, trademarks or products of International Business Machines Corporation or other companies. The name is unfortunate that the rmc solution requires a true LAN connection between the HMC and the partition. Associated with the real LAN connection is additional hardware requirements (LAN adapters and cables), additional configuration tasks (network management) And additional potential points of failure (lan connection). SUMMARY OF THE INVENTION A source endpoint that communicates between logically partitioned data logical partitions provides one of the source endpoints in this context. In a general-purpose transport primitive, the source processing system is a hardware management console and a logic computer implementation method. The method includes: by a source request or a response as a package of goods in a general use 146527.doc 201102805 points One of the hardware management consoles or one of the logical partitions of the data processing system, wherein the hardware management console is used for one of the split management The I-side, and the hyper-manager of the data processing system, transfers the general-purpose transport primitive from the source endpoint to a target endpoint, wherein the hyper-manipulator receives the source endpoint Encapsulating the generic transport primitive and forwarding the shipment of the generic transport primitive to the target endpoint, the shipment containing the request or the response, and wherein the receiving is performed by the hypervisor The goods are not inspected or parsed by the super-president in the transfer, and the target endpoint is the logical partition of the data processing system or the other of the hardware management consoles. Provided is a logically segmented data processing system. The logically divided data processing system includes: at least one processor including at least one logical partition; at least one external hardware management console; and a hypervisor, The at least one hardware management console is connected to the at least one logical partition interface. Each hardware management console is a user interface for split management. The hypervisor includes a In the a communication facility that communicates between the hardware management console and the at least one logical partition. The communication includes: packaging, by a source endpoint, a request or a response as a commodity in a general-purpose transport primitive, the source The endpoint is a hardware management console in the at least one hardware management console or one of the at least one logical partition; and the generic transport primitive is from the source endpoint via the hypervisor Forwarding to a target endpoint, wherein the hypervisor receives the generalized transport primitive encapsulated at the source endpoint and forwards the shipment of the generic transport primitive to the target endpoint, the cargo 146527.doc 201102805 = ' including the source endpoint and wherein the hypervisor does not verify or parse the shipment in the receiving and forwarding by the hypervisor, and the target endpoint is The at least one of the logical partitions in the logical partition or the other of the hardware management consoles in the at least one hardware management console. In another aspect, an article of a computer readable medium is provided, the at least one computer readable medium having a data processing system for facilitating logical segmentation - hardware management Computer readable code logic for communication between the console and the logical partition. When executed on a processor, the computer readable code logic performs the following operations: 丄 丄 仃 · · · · · · · · · 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由 由In the transport primitive, the source endpoint is one of the data processing system hardware management console or a logical partition, wherein the hardware management console is a user interface for split management; And via the data processing system - the hypervisor forwards the generic transport primitive from the source endpoint to the target endpoint, wherein the hypervisor receives the generic transport base encapsulated at the source endpoint Transmitting the goods of the ancient metaphysical transport base 7G to the target endpoint, the cargo containing the request or the response of the source endpoint, and wherein the receiving and the forwarding are performed by the hypervisor The goods are not inspected or cut by the hypervisor in the delivery.

And the target endpoint is the other one of the logical partitions of the data processing system. X Additionally, 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 as part of the claimed invention. [Embodiment] 146527. Doc 201102805 specifically states that it is regarded as the subject matter of the present invention, and the scope of patent application t at the end of the specification is clearly claimed. The foregoing and other objects, features and advantages of the present invention will become apparent from 'Logical segmentation is a technique for dividing a single-large computer system into multiple partitions'. Each of these partitions operates in some ways like an independent computer. Computer system resources can be allocated in any of a variety of ways for use by such dragons. - A given resource may be allocated for single-partition-specific use, or may be shared among all partitions (or some-sub-group of partitions) based on time interleaving or other means. Some resources can be allocated to specific points (4), while other resources are shared. Examples of severable resources are central processing n, main memory, 1/0 processor and adapter, and τ(4). Assignment to a logically partitioned computer system to those logical partitions ("in the sub-two: lights"), which means that only system resources assigned to the partitions can be used Or a resource component, rather than a resource assigned to another partition. Logical partitions are actually logical rather than physical. A general purpose computer typically has a physical data connection, such as a busbar that extends between different hardware components, allowing the different hardware components to communicate with one another. These hardware resources may be shared by different partitions and/or assigned to different partitions. From the point of view of physical configuration, it often does not make a distinction about logical partitions. In general, the logical partition is enforced by a partition manager embodied as a low-level encoded executable instruction and data, although there may be a _quantitative hardware support for the logical partition (such as the preservation of state information) Hardware temporarily 146527. Doc 201102805 The physical device of the system and its sub-components are usually physically connected to allow the pass-through without regard to the logical partition, and from the point of view of this hardware, there is no task written in the knife-cut area A Enter into a hidden or 1/0 device that is assigned to partition B. Low level code functions and/or hardware block access to resources allocated to other partitions. ▲ Logic partitioning of the code partitioning of the code generally means that it is possible to change the logical configuration of the logically segmented computer system, that is, to change the number of logical products or reassign resources to different partitions without Reconfigure the hardware. Typically, a portion of the logical partition manager contains a user interface for managing the low level code functions of the mandatory logical partition. This logical partition manager interface is intended for use by a single or a small group of authorized users (indicated as system administrators in this document). When used in this article, this low-level logical split code is called the HyperManager, and the split manager interface is called the Hardware Management Console. ° There are several potential advantages to the logical partition of a large computer system. As mentioned above, the flexibility is that it is easy to reconfigure and redistribute resources without changing the hardware. It isolates tasks or task groups, thereby helping to prevent any task or task group (4) breaking system resources q to facilitate the adjustment of resources provided to specific users; this is where the computer system is owned by the service provider Important 'The service provider provides computer services to different users in a way that charges each time a resource is used. It enables a single-computer system to simultaneously support multiple operating systems and/or environments, as each logical partition can execute a different operating system or environment. Finally, the separation of tasks and resources makes it more difficult to execute procedures in a partition. 146527. Doc 201102805 To access resources in another partition, Tian provides the safety and integrity of the car. Referring to the drawings, wherein the same number of first digits represents the same parts throughout the several views, FIG. 1 is a high level J of a particular hardware component of a logically separable computer system 100 having a plurality of physical components. Ask the level table not. At the functional level, the main components of the system 10 are not shown as dashed outlines in Figure 1; these components include: - or a plurality of central processing units (CPU) 101, main memory 102, The service processor 101, the terminal interface 106, the memory interface 1〇7, the vertical 1/〇 device interface 1〇8, and the communication/network interface (10), all of which are coupled via one or more bus bars 105 Used for communication between components. The CPU 101 is one or more idle general-purpose programmable processors that execute instructions stored in the memory 1G2; the system may just contain a single-CPU or multiple CPUs (any of which - the situation is collectively The feature cpu represents) and may include - or multiple levels of onboard cache memory (not shown). Typically, a logically partitioned system will contain multiple CPUs. The memory 102 is - for storing (four) and program random access half " memory. Memory 102 is conceptually a single-monolithic entity, it being understood that memory is often configured in a hierarchical architecture of cache memory and other memory devices. In addition, the memory 102 can be divided into a specific CPU or CPU group and a specific bus bar, as in any of the so-called non-coherent memory access systems. Service processor 103 is a specialized functional unit for initializing system, maintenance, and other low-level functions. The body A does not execute the user application, and the CPU 101 executes the user application. In an embodiment, 146527. Doc 201102805 Service Processor 1 03 and the attached Hardware Management Console (HMC) 114 provide an interface for system administrators or similar personnel to allow a person to manage the logical partitions of the system 10 . The terminal interface 106 provides a connection for attaching one or more user terminals 1A to i2ic (collectively referred to as 丨 21), and the terminal interface 1 〇 6 can be implemented in various ways. Many large server computer systems (mainframes) support direct attachment of evening terminals via a terminal interface I/O processor (usually on one or more electronic circuit cards). Alternatively, interface 1 〇 6 provides a connection to the local area network to which terminal 112 is attached. Various other alternatives are possible. The data storage interface 107 is provided to one or more of the data storage devices 122 to 1220: (collectively referred to as 122), the one or more data storage materials are rotating magnetic hard disk drives, and other Type of data storage device. 1/〇 and other device interfaces 1〇8 are provided to any of a variety of other input/output devices or other types of devices. Two such devices are shown in the exemplary embodiment of FIG. 1 : printer 123 and fax machine, there may be other such devices in the future, and can provide self-system for different types of communication interfaces 1 〇 9 (10) Paths to other digital pirates and computer systems - or multiple communication paths ^ may include, for example, or multiple networks 126 (such as the Internet, a regional network, or other network)' or may include far End device communication lines, wireless connections, and the like. S 1 ^ ^ ^ ^ ^ ^ Μ # ^ ^ ^ Round 1 肀 Table No % - Conceptual Confluence . . ^ Brain system Gu Keshi Bridge body 105 ' But should know, typical electric system. . First, there are multiple confluences ^ pkb « , s , , 逋 often in a complex topology configuration, P white layered star or mesh configuration in the town. · Occupy point links, multiple hierarchical sinks 146527. Doc -12- 201102805 Streaming, parallel and redundant paths, etc., and there may be separate busses for communicating specific information such as 'address or status information. In the embodiment, in addition to various speedy busbars for data communication as part of normal data processing operations, 'I2C protocol special service busbars are used to connect various hardware units' to allow service processors or other Low-level handlers perform various functions independently of high-speed data, such as powering on and off, reading data identifying hardware units, and so on. Usually the primary entity unit is replaced by one or more fields. Typically, this Field Replaceable Unit (FRU) is an electronic circuit card set. However, the physical unit does not need to be an electronic circuit card set. It may alternatively be a component such as a disk drive storage device 122, a terminal machine 121, a power supply, etc., and another single body unit may have one or more therein. For larger systems, the 'single-primary functional component (such as cpu(8) or memory1〇2) will typically contain multiple entities in the form of an electronic circuit card set, although (four) generationally, more than one main function It is possible for a component to reside in a previous physical unit. In Figure 1, CPU 1〇1 is represented as containing four circuit cards 111A through 1UD, each of which may contain - or multiple processors; memory 102 is represented To contain six cards U2A to n2F; the service processor (8) is represented as containing a single card 113; the busbar 1〇5 is represented as containing three cards 115A to 11 5C, and the terminal interface 106 is represented as containing three cards u 6A to U6C; the memory interface 1〇7 is shown to contain two cards 117 8 to 117B; the I/O and other interfaces 108 are shown as containing two cards 118A to; and the k interface 109 is represented as containing two Cards H9A to ii9B. It should be understood that 'Figure 1 is intended to depict an exemplary data processing system at the southern level 〇 146 146527. Doc -13- 201102805 Representative components 'Individual components can have a greater complexity than the components represented by the diagrams. The number, type and organization of these functional units and physical units can vary significantly. Further, it should be understood that not all of the components shown in Figure 1 may be present in a particular computer system' and other components may be present in addition to those shown. Although the system is multi-user system with multiple terminals, the system (10) may alternatively be a single-user system, which typically only contains a single user display and keyboard input. Figure 2 shows the computer system, system! A conceptual description of the existence of logical partitions at different hardware and software abstraction levels. Figure 2 shows a system with four logical partitions 2〇4 to 2〇7 (designated as "segment 1", "segment 2", etc.) that can be used in the user application. It should be understood that the number of partitions 2 Can be changed ° As is well known, the computer system is a sequential state machine that executes the processing program. These handlers can be represented at different levels of abstraction. At the high abstraction level, the user specifies - the order and the input, and the output is output. When proceeding to a lower level, it can be found that the handlers are sequences of instructions written in a programming language that are translated into lower level instruction sequences as they continue downward, and are authorized The code, and eventually becomes a data bit, which is entered into the machine register to cause a particular action to be performed. At a very low level, the changing potential causes various dielectrics to turn "on" and "off". In Fig. 2, the 'higher' abstraction level is represented as the top of the pattern' and the lower level is shown as facing the bottom. As shown in Figure 2 and explained earlier, the logical division is a concept of code execution. At the hardware level 201, there is no logical partition. .  As used herein, the hardware level 2 〇 1 represents the entity 146527 shown in Figure i. Doc • 14- 201102805 (not the data row, I/O device, etc. stored in the device) _ processor, memory, sinking his hard TM two: order. In the embodiment, each is processed two, which: the execution of the machine level refers to. Although the code can guide the specific switching on the Υ Υ θ.  .  The task in J £ is executed on a specific processor, but this assignment is made in the processor itself, and in fact the assignment can be changed by the code. _ .  „ — Therefore, the hardware level in Figure 2 is not the same as the early consistency 2〇1, and there is no difference between the self-contained and the logical partition. The fault is divided by a split manager (called “super-manager”). , consisting of - non-relocatable non-WR part 202 (also known as "non-dispatchable hypervisor" or "split authorization inner code" or "pLIr, C") and a relocatable dispatchable part 2〇3) Force splitting. The hypervisor is a super privileged executable program 2, which is sufficient to access resources assigned to any partition (such as processor resources and implicit entities). The super-status maintains state data in various dedicated hardware registers and in tables or other structures of the general-purpose memory, which control the boundaries and behavior of the logical partition. This status profile specifically defines the resource allocation to the logical partition' and changes the allocation by changing the status data rather than reconfiguring the entity of the hardware. In an embodiment, the non-dispatchable hypervisor 2〇2 contains non-relocatable instructions executed by the CPU 1〇1, just as a deduction for tasks performed in the partition. The code is non-relocatable, which means that the code that constitutes the undispatchable super processor is located at a fixed real address in the memory. The non-dispatching super-orientation device 202 can access the entire real memory range of the system 100 and can be aware of the vertical real memory address. The hypervisor code can be assigned 2〇3 (and 146527. Doc •15- 201102805 All partitions are included in the address associated with a logical partition assignment, and therefore this code is relocatable. The hypervisor can be dispatched to operate in much the same way as the user partition (and sometimes referred to as "partition" because of &, but it is hidden from the user and is not available for execution) User application. In general, the non-dispatchable hypervisor handles task assignments to the physical processor, memory mapping and partition enforcement 'and the necessary necessary partitioning tasks required to execute the application code in the partitioned system, and can assign super Manager 2〇3 handles maintenance-oriented tasks such as establishing and changing partition definitions. As shown in Figure 2, there is no direct path between the higher level (the level above the non-dispatchable hypervisor) and the hardware level 201. While machine instructions for tasks performed at higher levels can be executed directly on the processor, access to hardware resources is controlled by an undispatchable hypervisor. The non-distributable hypervisor 202 enforces a logical partition of processor resources. That is, the task dispatcher at the higher level (the individual task system) dispatches the task to the virtual processor defined by the logical sub-parameter, and the ride manager dispatches the virtual processor to the entity processing at the hardware level 201. Used to perform basic tasks. The hypervisor also enforces partitioning of other resources (such as allocating memory to partitions) and delivering 1/0 to the I/O devices associated with the appropriate partition. The dispatchable hypervisor 203 performs the jurisdiction of not any partition (the many auxiliary system functions called by prcm. The dispatchable hypervisor usually manages higher level partition management operations, such as creating and deleting partitions, while hardware Maintenance, processor, memory and other hardware resources are divided into 146527. Doc 201102805 is equipped with various partitions and so on. The dispatchable hypervisor can specifically handle access to the indicator light. The assignable hypervisor 203 can include a status data structure of the visual indicator 22 1 , a status data structure to the partitionable entity allocation 222 of the partition, and a status data structure of the separable physical location 223 'which can be associated with the hypervisor The code is used to adjust access to the physical indicator and to activate and deactivate the physical indicator. A special user interaction interface is provided to the dispatchable hypervisor 203 for use by system administrators, service personnel, or similar authorized users. In a consistent example, where the system 1 includes a service processor 1 〇 3 and an attached hardware management console 114, the HMC 114 provides an interface to the dispatchable hypervisor for use in Service and partition management, and will be assumed in this description. Above the non-dispatchable hypervisor 202 is a plurality of logical partitions 204 through 207. Each logical partition (from the point of view of the processing program executing within it) operates as an independent computer system with its own memory space and other resources. Each logical partition thus contains a separate operating system core, which is identified herein as r 〇s cores 211 through 214. The 层s core level and _L 'per-partitions operate differently, and thus Figure 2 represents the OS core as four different entities 211 to 214 corresponding to four different partitions. In general, each 〇8 core 21丨 to 214 performs a substantially equivalent function. However, it is not intended that all of the 〇S cores 211 to 214 are identical copies of each other, and that they may be different versions of an architecturally equivalent operating system, or even architecturally different operating system modules. The QS cores 211 to 214 perform various kinds of tactics such as task assignment, paging, and enforcement of multiple tasks. Doc 201102805 data integrity and security, and so on. Above each of the os cores in each of the individual partitions, there may be a set of high level operating system functions, and the user application code and data (not shown). The user can create code on the OS core and level. The code calls the high-level operating system function to access the OS core, or the code can directly access the os core. In the CongyiTM operating system, a user-accessible architecturally fixed "machine interface" forms the upper boundary of the os core (os core called SLIC), but it should be understood that different operating system architectures can be differently This interface is defined and it will be possible to use logical partitions to operate different operating systems on a common hardware platform. One of the logical partitions is designated as a service partition as appropriate. In Figure 2, partition 205 is designated as a service partition, which is a partition that is assigned for use by system maintenance personnel to perform various management and maintenance functions. This service partition can be used exclusively for management and maintenance functions, or it can be used for user applications. However, where the system contains a hardware management console 114 (as shown in the illustrated embodiment of Circle 1), most of the service and maintenance functions are performed from the hardware management console rather than the service partition. As mentioned initially, the basic problem addressed by the present invention is the need for a generalized communication facility between the hardware management console (HMC) and the logical partition of the logically cut data processing system. The system is for example by Armonk, New York, U. S. A. ) The Power® computing system offered by International Business Machines Corporation. A data processing system that implements a hypervisor-based communication facility (such as described below) as a specific commercially available example can be based on 146527 found in IBM's p/i Series product line. Doc 201102805 Firmware and technology in systemware (as in Power.) Org (http://www. Power. Org/members/developers/specs/PAPR_Version_ 2. 7_090ct07. This material is hereby incorporated by reference in its reference to the "High Strength Computing Architecture Platform Reference" (PAPR) material, which is hereby incorporated by reference. (IBM®, pSeries®, iSeries®, and Power® are international commercial machine companies (Armonk, New York, U. S. A. ) registered trademark. The communication facilities presented in this paper can be used for system management tasks such as simultaneous hardware maintenance, dynamic logic partitioning, inventory collection, virtual I/O device mapping, and more. This hypervisor-based communication facility is a general-purpose, low-latency, fully asynchronous communication method between the HMC and the logical partition. This is in contrast to existing communication facilities that are non-universal or require additional physical connections between the HMC and the logical partition (such as real LAN connections and additional configuration tasks). In general, a robust, zero-maintenance, low-latency, fully asynchronous, robust communication facility between the HMC and the logical partition is presented herein, which is implemented in the hypervisor. The communication facility implemented by this hypervisor is referred to herein as a hypervisor pipeline. The versatility of the hypervisor pipeline is that it is not specific to any particular type or class of commands or flows between the HMC and the hypervisor (or between the hypervisor and the logical partition) (such as dynamic logical partition versus virtual I) /O 'non-synchronous pair synchronization, etc.). The hypervisor pipeline is zero-maintained in the sense that the pipeline itself is unaware of the specific commands (i.e., requests and responses) that are flowing between the HMC and the logical partition. These particular commands are treated as goods that reside in a basic or general transport primitive that flows through the hypervisor pipeline. Hypervisor identification of general use transmission 146527. Doc •19· 201102805 Base 7L 'but does not examine or dissect the goods contained in the generic transport primitive. Therefore, when a new command stream is introduced between the HMC and the logical partition, the hypervisor is not affected. * Super-organic channels are designed to minimize waiting time for communication through the pipeline. The waiting time caused by the hypervisor is mainly the direct memory access (DMA) of these communication streams to the flexible service processor (FSp), which is the component by which the HMC communicates with the hypervisor, or the flexible service processing. Benefit (FSP) Direct § Memory Access (DMa) The time required for the communication streams and the communication streams to be logically partitioned from the DAS or from the logical partition. The processing by the hypervisor pipeline is mainly the delivery, pacing and statistics collection between one or more HMCs and one or more logical partitions. In order to minimize the system resource requirements (ie, memory, buffers, tasks) of the hypervisor pipeline while maximizing the throughput of the hypervisor pipeline and preventing a bad operation (ie, not responding in time) The logical partition or HMC negatively affects the throughput of other partitions and HMCs. The super-management is essentially non-synchronous and uses a separate buffer pool for each logical partition and per-HMC (ρ 〇〇ι). In other words, if [H1 starts from one to the partition? 1 communication flow, but ρι is extremely busy or hung and does not respond, then the hypervisor will always deliver the communication flow to P1 without buffering the buffer buffer, and then respond to m (After the ?1 does not respond, then H1 can wait for the response flow from the time!>), or if the P1 buffer pool at the super-experimental device is exhausted, the hypervisor is busy. The status responds to HMC H1. Pipeline tasks and hypervisors are not blocked 146527. Doc •20· 201102805 and via dk) The wait for a response or response from the HMC or partition, the busy state or the timeout of the communication flow itself, passes the disposition-free target back to the source of the communication stream. The robustness of the hypervisor pipeline presented in this article is that there are no input/output (I/O) adapters and communication cables' to reduce the chance of a configuration problem. μ Therefore, a hypervisor-based communication facility (ie, hypervisor = track) is interfaced between the logically partitioned data processing system 2HMc (external management device) and the logical partition. The hypervisor pipeline is a generic: L «reconciliation, so that it can handle only ^1 (: many types or categories of streams/commands between logical partitions. Hypervisor pipelines only recognize the basic transport base疋, rather than a specific command (request or response) that flows between the HMC and the logical partition (which is considered a simple cargo or additional material), and therefore whenever a new command between the HMC and the logical partition, The hypervisor pipeline is unaffected when a request or response flow is introduced to the data processing system. The hypervisor pipeline can deliver traffic between one or more HMCs and one or more logical partitions, and does not allow no response. The partition or HMC blocks the transmission of traffic or negatively affects the performance of their flow to and from other partitions or HMCs. The communication facilities presented herein are superior to the conventional RMC resource management mechanisms described above because they are not required Separate cross-LAN connection between each HMC and the logical partition, thereby reducing hardware requirements (no lan adapter), configuration effort (no network management, cabling), and failure rate (no adapter or cable) Failure). , Still connected to the management system having a plurality of logical partitions, I46527 a network between each Held HMC HMC and management of the system. Doc 201102805 The communication facilities presented in this paper show a potentially significant reduction in network extra load compared to the RMC resource management mechanism. Figures 3 through 5 depict three different views of a hypervisor tube in accordance with aspects of the present invention. In FIG. 3, a solid frame view is presented, wherein the logically partitioned data processing system 300 includes a plurality of logical partitions 31 (labeled ρι, ?2, and P3), including the hypervisor pipeline described herein (or a hypervisor 320 of the communication facility 325, a flexible service processor 33A, and a plurality of hardware management consoles (HMCs) 340 that are networked to the super via a flexible service processor (FSP) 330 Manager 32〇. The communication between the Fsp 33〇 and the hypervisor 320 is via direct memory access (DMA), and the hypervisor and logical partitions also communicate via a form of partitioned interval DMA. The super-B processor pipeline component in the super-g processor performs flow delivery, adjustment progress, and statistical data collection. 4 depicts a lower level logical view of the data processing system 3, where the HMC 34G and the hypervisor 32G (or more specifically, the hypervisor pipeline 325) establish a logical HMC command session via the FSP 330. . As shown, there is a single-communication session 400 between each listener and hypervisor. Associated with each HMC to the hypervisor session is the §fl buffer pool 4 〇 5 in the hypervisor pipeline. As follows, whoever + ^ r progresses and explains this message buffer is used to implement a hypervisor-based communication facility between the HMC and the logical partition. Similarly, the logical partitioning and the hypervisor establish a logical segmentation event, and the communication flow is exchanged via the general-purpose transport primitives on the logical segmentation event. For each-logical partition to the hypervisor session 146527. Doc • 22· 201102805 410 again defines a separate message buffer pool 415. In operation, the hypervisor parses the generic primitive transfer commands to determine the target and move the goods between the respective HMCs and the logical partitions. In one implementation, 'in addition to the general purpose transport primitives', three types of session management requests are used, that is, between the HMC and the hypervisor pipeline (and each logical partition in the hypervisor pipeline). Between the use of open communication session request, close communication session request and exchange capability request. Thus, in one embodiment, a request from an HMC or a logical partition may include an open request, a switch capability request, a close request, or a general transfer primitive (referred to as a HypePipe request in the logic flow described below). 5 depicts a logical representation of a higher level of data processing system 3, wherein the logical pipeline presented herein can be considered to establish each listen 340 and each partition-to-point, logical HMC via data manager 320. The communication period for the partition is 5〇〇. This figure is a conceptual view of the communication frame at its highest level. The endpoint in the HMC sends the communication stream to the endpoint in the logical partition and vice versa. 6 through 10 depict a consistent embodiment of implementing a super-manager-based device (such as the hypermanipulator pipe) logic of a hypervisor-based device, such as Figure U to Figure 13 depicts a particular endpoint logic flow that may be implemented within an HMC or logical partition in accordance with aspects of the present invention. Referring first to Figure 6, the hypervisor & When used in this article, the original point is HMC or logical partition, = can include a session management request (such as opening a session request, exchanging this request or _ session please 峨 super-channel (or office (four) 146527 . Doc -23· 201102805 Request. The hypervisor pipe request is a generic or basic transport primitive as described in this article. The endpoint uses this primitive to communicate via the hypervisor pipeline. In one embodiment, the general purpose transport primitive has the following data structure: target endpoint ID | cargo length 丨 cargo (encapsulated request or response communication) 丨 super manager initial decision to receive source endpoint request 605 is An open session management request or an exchange capability session management request 6 丨〇 ^ if 任 者 ', then set the session state between the source endpoint and the hypervisor to enable 615 'and in the hypervisor The capability set by the source endpoint is set to 62〇. The answer status (ACK status) is set to success 625 and the response (including its status and adjusted capabilities) is passed back to source endpoint 630. If the source endpoint request does not open the session management or exchange capability session management request, the hypervisor determines whether the s request is a closed session management request 6 3 5 . If so, the expiration state between the source endpoint and the hypervisor is set to off 64〇, and any queued or pending requests 645 for the duration of the session are canceled. The hypervisor sets the state to success 650 and sends a reply with the attached state back to the source endpoint 630, then returns to wait for the next source endpoint request. If the source endpoint request is not a session management request, the hypervisor determines if it is a basic transport primitive (i.e., a hypervisor pipe (or Hypepipe) request). If "yes", the hypervisor returns from the query 655 to perform the process 66 of Figure 7 (described below) to wait for the next source endpoint request. If the source endpoint request is not a session management request or a hypervisor pipe request, then the request is an unrecognized request, and thus the response status is set to error 665 and a response 630 with an error status is returned. Assume that the hypervisor pipeline receives the hypervisor pipe from the source endpoint 146527. Doc •24· 201102805 Seeking (ie, general-purpose transport basis), the logic flow of Figure 7 is performed. The hypervisor pipeline determines if the generic transport primitive has an acceptable cargo size (i.e., has a size less than or equal to the maximum transfer unit (MTU) size) 700. If "No", the response status is set to ]^[11; violation 7〇5, and the hypervisor returns 770 to the logic of Figure 6. Otherwise, the hypervisor determines if the target endpoint identification is valid endpoint identification within the data processing system. If "No", the response status is set to an invalid parameter 7丨5, and the hypervisor returns 770 to the logic of Figure 6. Assuming the cargo size and target endpoint are recognized as acceptable, the hypervisor determines if the target message buffer pool is empty 720. If "yes", the answer status is set to busy 725 and the hypervisor returns 770. Otherwise 'take out a target message buffer 730' from the target message buffer pool and create a new hypervisor pipe request (ie, target transport primitive) in the target message buffer, which includes the goods from The source hypervisor pipe request (ie, the source transfer primitive) is copied to the target hypervisor pipe solicitation 735. Once the target transport primitive is built, the hypervisor determines if the target endpoint's duration is on. If "No", the response status is set to the expiration of 745, and the hypervisor returns 770 to the logic of Figure 6. Otherwise, the hypervisor determines whether it is in the process of interacting with the target endpoint (i.e., the session state is an exchange capability or a wait capability response) 750. If "yes" then the response status is set to busy 755' and the hypervisor returns 770 to the logic of Figure 6. Otherwise, the target transport primitive is sent asynchronously to the target endpoint 760, and the reply state is set to success 765, after which processing returns to 770. Figure 8 depicts a 146527 for processing hypervisor logic from a response from an endpoint. Doc 25· 201102805 Example. The hypervisor waits for a reply 800 from the endpoint. Upon receiving the J 805, the hypervisor determines if the response is an exchange capability response 81〇. If "yes", the hypervisor determines whether the endpoint fulfills (h〇n〇r) the processor's ability to look at 8 1 5 . If YES, the endpoint-to-hypervisor session status is set to 820, and the message buffer used in the exchange capability request is passed back to the respective endpoint message buffer pool 825. If the endpoint does not fulfill the hypervisor capability, then only the message buffer is passed back to the respective endpoint message buffer pool' without setting the endpoint to hypervisor session state to on. After the message buffer is returned to the corresponding endpoint buffer pool in the hypervisor pipeline, the hypervisor determines whether the session status is required to exchange the duration status 830. If "No", then the processing is processed. Return to wait for a response 800 from the endpoint. Otherwise, logic 835 of Figure 9 (described in the text) is executed. The response received by the right is not an exchange capability response, and the hypervisor determines if the air response is a hypervisor pipe response 840. If "Yes", check the status of the attached return to see if it is - you need to exchange: #^. If yes, the status is set to the required transmit capability and the endpoint message buffer is sent back to the corresponding endpoint message buffer pool. If the response received is not the exchange capability or the hypervisor pipe response ^ ° ° . The manager fails to recognize the response 855 and returns to wait for the next-and-successive state to assume that the status of the response to the received response is the need to exchange, then from 830, the logic 835 of Figure 9 is executed. This logic performs a hypervisor exchange with the corresponding endpoint (with which communication session is established). The capability exchange γ is compliant with one of the required exchange capabilities. The communication session responds to the U state, the hypervisor from 146527. Doc • 26· 201102805 The corresponding message buffer pool gets the game component—the endpoint message buffer 9〇〇, and it is built in the message buffer—exchange, month b force request 905. Then, the communication manager's communication session status is set to the waiting capability response 91〇, and the hyper management writes asynchronously sends the exchange capability request to the respective endpoint 915 of the communication session, and then returns to the time when the logic is called. Logic flow 920. . Figure 10 depicts an example of a logic that can be used to process a capability change event within a data processing system. In the event of a capacity change event, consider the time of each HMC 1〇〇5. For example, the capability change event may be a simultaneous update of the super-e-bene determination to determine whether there is still a hmc session (8) to be considered, and if "yes", Bj1 gets the next-HMC (4)15. The status of the session of the HMC session is set to require the exchange capability, and the hypervisor determines whether the target HMC message buffer pool is empty. If yes, consider the next HMC session period of 1〇〇5. Otherwise, perform the logic ι〇3〇 of Figure 9, and then the hypervisor returns to evaluate the next-HMC session...has processed all the term sessions' then since the query 1G10's hypervisor evaluation per-logical segmentation (Lp) The meeting will be 1035. The hypervisor determines if there is another open communication session 1040' and if "no", the capability exchange logic has completed 1 () 45. If there is another LP session to be considered, the next communication session is obtained 1〇5〇, and its session status is set to require the exchange capability 1〇55. The hypervisor determines whether the message buffer pool of the target logical partition is empty 1〇6〇, and if YES, processes the next LP session. If the message buffer pool is not empty, then the logic 1 〇 65 of Figure 9 is performed for the obtained LP session. Figure 11 depicts an embodiment of endpoint logic for processing hypervisor pipe requests (generic transfer primitives) within a logical partition or HMC. The endpoint waits for 146527. Doc 27· 201102805 A hypervisor pipe requests blue, and upon receipt, 11货物5 copies the goods to a local buffer 1110. The endpoint then determines if the shipment contains a valid endpoint request 1115. If YES, the endpoint responds to the hypervisor pipe request i i 2 G with a success status. The endpoint then determines if the spot request source switching capability 1125 is required. If "yes", a response is sent to the source m in response to a new hypervisor pipe request as a shipment. The response contains a status 1130 indicating the need for switching capability. If there is no need to exchange capabilities with the source endpoint, then the target endpoint processes the request 1135 and determines if a response to the request is required 1140. If "no" then the endpoint returns to wait for the next hypervisor pipe request. No shell,! Generating a response and encapsulating it as a new hypervisor pipe request sent back from the target endpoint to the source endpoint, the response having a result based on processing the first hypervisor pipe request at the target endpoint While the set state 1145 » The right cargo does not contain a valid request, the endpoint determines if the shipment contains a valid response 1950. If YES, a response to the hypervisor pipe request is sent, wherein the status is set to success 丨丨 55, and the endpoint determines whether the response is for the exchange capability request 116 〇 β if “No”, then the response is processed. 1165, and if "yes", the target endpoint records the fact 1170 that the capability has been exchanged with the source endpoint. If the shipment does not contain a valid request or a valid response, then a response 1175 to the hypervisor pipe request with an error status is sent. Figures 12 and 13 depict two methods for exchanging capabilities in response to a capability change event at an endpoint. Figure 12 is the active method and Figure 13 is the passive method. Referring first to Figure 12, the endpoint logic determines that one of the endpoints may have changed 146527. Doc -28- 201102805 The event of force has occurred 12Q(). For example, an endpoint power up or a simultaneous boost has occurred. The endpoint logic sets the capability exchange state to indicate that all endpoint switching capabilities 12〇5 have not been aligned, tracking capability exchange status. A switch capability request is then sent to the hypervisor 121G. In an embodiment, the pair: power on can be 35 to exchange capabilities by opening a session request instead of an exchange capability request. After considering all possible target endpoints 1215, the primary endpoint (4) 卟 ct endpoint determines if there is another endpoint 122 to be considered. Right: Yes, the next endpoint 1225' is obtained and a request for the transactional pipeline request for the goods is sent to the endpoint. Once all endpoints have been considered, processing is completed 1235. In alternative method t, the logic of Figure 13 can be used to exchange capabilities in response to a capability change event in an endpoint. In this method, an event occurs that may have been handed over to the ability in the master knowing point, such as a simultaneous update of n〇〇. The capability exchange record at the primary endpoint is changed to indicate that all endpoint exchange capabilities have not been exchanged for the capability being tracked. The endpoint then sends an exchange capability request to the hypervisor n131G. Looking again, powering on (4) points can exchange capabilities with the hypervisor by opening a session request instead of an exchange capability request. Once the exchange capability request has been forwarded to the super processor, processing is completed 1315. In this approach, the endpoint does not actively push the switching capability request to other endpoints, but will wait for other endpoints to initiate a traffic flow and will respond to the traffic flow with a required exchange capability state. For further explanation, various command structures for implementing the hypervisor-based communication facility described above in, for example, the IBM P0 Gift 8 computing system are described below. The following discussion is provided as an example only, and should be considered 2, 146527. Doc -29- 201102805 The scope of the patent application presented with this specification is not limited to the specific embodiments presented below. Terms and concepts are used herein to use the following terms: • Upstream - In this context, based on a common view of a logically partitioned system (including HMC) with partitions located above the firmware, the upstream refers to a self-HMC The flow to the partition. • Downstream - In this context, based on the common view of a logically partitioned system (including HMC) with partitions located above the firmware, downstream refers to a flow from the partition to the HMC. • Inbound - In the context of the ingress and egress and HMC flows, the entry refers to the flow into the partition or HMC, which should be resolved from the point of view of the HMC or partition rather than the hypervisor (HYP). . • Out – In the context of entering and leaving the partition and the flow of the HMC, the entry refers to the flow leaving the partition or HMC. The term should be interpreted from the perspective of HMC or partition rather than ΗΥΡ. High-level flow This section discusses the main interactions and events that occur between subsystems involved in the hypervisor pipeline flow and in subsystems. Two methods for packetizing the response data associated with the upstream request from the HMC to the partition are possible. The first method is a "pull" method whereby the source endpoint of the request sends one or more GetRemainingResp〇nseData streams to the target of the request after obtaining a response to the initial request until it has been retrieved. All relevant response information. No. 146527. Doc -30- 201102805 The two methods are the “push” method, whereby the target of the request repeatedly sends a response flow for the request until all response data associated with the request is passed back to the source of the request. The benefit of the pull method is that it allows the source of the initial request to retrieve data at its own rate. The benefit of the push method is that it involves a generally small flow through the hypervisor pipe, and it allows the target to immediately send all response data back to the source without having to deal with situations where the source directly discards the remaining data. A potential disadvantage is that if the target sends back a number of response streams in close proximity, it can get a "busy" status from the hypervisor. This can be aggravated if other partitions are sending streams to the same HMC at the same time. In addition, in theory, the packet may be lost, which means that the HMC should monitor this situation and should retry the initial request in the event of a loss. By pulling the method, the HMC will only retry the failed GetRemainingResponseData stream. Open Session This is an HMC message interface. The HMC uses the HMC message interface to open a session with the hypervisor and exchange with the hypervisor. A session can be opened for each attached HMC. For a single HMC, multiple sessions cannot be opened. In the parameters below, the entry and exit are from the perspective of HMC. Open the session request parameter: 146527. Doc •31 - 201102805 Name Description Maximum number of incoming messages The maximum number of incoming messages that are unprocessed Maximum number of outstanding outgoing messages The maximum number of outgoing events The number of capability bytes The number of capability bytes is the number of capability bits Each bit of the group represents a capability. The HMC initiates a bit indicating its ability to support, and the hypervisor closes its bits indicating its unsupported capabilities. Open session response parameters: In addition to the "Maximum incoming message" and "Maximum outgoing message" will contain the hyper-reporter counter proposal (which will always be less than or equal to the number specified by the HMC), the response parameters The capability bit mask will be the same as the mask passed in the request, except for the request parameters, and except that the bits representing the capabilities not supported by the hypervisor are turned off. The hyper-manager will have a maximum of 8 and 1 for the "maximum entry event" and "maximum exit event". If the HMC specifies a higher value, the hypervisor will deny this value. If the HMC specifies a lower value for some reason, the hypervisor will perform the lower value, but the pipeline throughput can be negatively affected. An initial value of zero will result in a GenericError. Open the session status code: Pass back in the common header. No command specific return code. Possible values • Good • InvalidOpcode • GenericError • InvalidState - Issues a start-up period at the same time as the session is started. 146527. Doc -32- 201102805 Close Session This is an interface through which the HMC closes the command period with the Hypervisor. There are no request or response parameters, and there are no session-specific return codes. Switching Capability: This is an HMC message interface. The HMC and HyperManager exchange capabilities through the HMC messaging interface. This command can be sent multiple times during the duration/life of the session. The command can be sent immediately after the opening session, and/or later when the session is actually used. HMC and HYP must support this command as both source and destination. If the capabilities of the HMC or Hypervisor change due to simultaneous firmware updates, this command can be used to exchange capabilities (assuming non-simultaneous firmware updates will cause the session to close and an open session to occur after the update). Each of the two entities must verify that their current capabilities have been exchanged with the source whenever they receive a flow that is not an exchange capability. If not already exchanged, the ExchangeCapabilities return code must be returned. If an event that changes or may have changed the ability of the target occurs, the target must exchange capabilities with all sources again. Request Parameter ‘· Name Content Description Number of Capacity Bytes Number of Capacity Bytes Below Capacity Bytes Each bit represents a capability. The source initiates a bit indicating its ability to support, and the target closes its bits indicating its unsupported capabilities. Response parameters: The response parameters are the same as the request parameters except that the bit indicating that the capability is not supported by the target is off. 146527. Doc •33- 201102805 Return Code: Pass back in the common header. No command specific return code. Possible values are .  • Good • InvalidOpcode • GenericError Hyper-Manager Pipeline Request: This is an HMC message interface that the HMC communicates directly with the partition via the HMC message interface. The hypervisor acts as a simple pipe. It does not examine the data that is piped through the pipe to the partition or from the partition. It accurately copies the data area (goods) without modification. This is a completely asynchronous command. When the HMC sends the command to the hypervisor, the hypervisor routes the goods within the command to the specified partition. When a partition sends a stream destined for the HMC to the hypervisor, the hypervisor sends the command along with the goods from the partition to the designated HMC. All timings for these orders are the responsibility of the HMC and the division. Request parameters: Name Description of content Source/target ID For outgoing (from HMC to HYP) streams, the HMC is set to the target ID. For incoming (from HYP to HMC) streams, HYP is set to the source ID. Cargo Size The size of the following goods (in bytes). For turbulences that target partitions, this value cannot exceed 160 bytes, and for inbound turbulence with HMC as the target, this value cannot exceed 1488 bytes. Goods goods 146,527. Doc -34- 201102805

Ack parameters: Name Description Return code See “Return Code” below. Length of extra return code data. Extra return code. Length of specific data (if any) (in bytes). Additional return code data. Additional return code specific data (if any) Return code: • Success • Failure • Busy • InvalidParms • PipeClosed • MtuViolation (: Mtu violation) • ExchangeCapabilities (return capability) return code:

Success(>§fe' ·* successfully completed the request. Recovery: N/A Failure: The request failed with no other information. Recovery: Retry the request. If the problem persists, start the standard analysis.

Busy: The request was not executed because the request target (or possibly the hypervisor) is busy. This situation is expected to be temporary. 146527.doc -35- 201102805 Recovery: After a short delay, retry the program. If the condition persists for an extended period of time (i.e., several minutes), there may be an error in the target or hypervisor. invalidParms (invalid parameter): The request was not executed because the command contains invalid or unrecognized parameters. Invalid The target ID is an instance that will cause the status of this return code. Recovery: none

PipeClosed: The request was not executed because the pipe that arrived at the specified target was closed or not active. This can indicate that the target is powered down or in a fault condition. Recovery: Power up or IPL the target.

MtuViolaiion (Mtuxi Μ): The size of the specified item exceeds the maximum transfer unit (MTU). Additional Information: Bytes Description 0-3 Supported MTU Size Recovery: Retry with a supported cargo size. ExchangeCapabilities: The request was not executed because the capabilities of the target may have changed since the last exchange capability. Recovery: Issue an Exchange Capabi丨ities request and then retry the failed request. Logical Segmentation (LP) Event: Open Session: 146527.doc -36- 201102805 This is an LP event interface. The partition uses the LP event interface to negotiate with the hypervisor during the session open protocol and the maximum entry/ Depreciation. The partition is always the source/starter of the event, and the hypervisor is always the target. This event cannot be sent again after the session is turned on. The session management code monitors the event ID and if it occurs after the session is turned on, the term management code will reject the transmission. In the parameters below, the entry and exit are from the point of view of the partition. Request parameters: Name Description Event ID Event code. Maximum number of events The maximum number of unprocessed events. Maximum outbound event The maximum number of unprocessed outbound events. Number of capability bytes The number of capability bytes below The capability byte Each bit represents a capability. The partition initiates a bit indicating its ability to support, and the hypervisor closes its bits indicating its unsupported capabilities. Response parameters: In addition to the "maximum entry event" and "maximum exit event" will contain the hyper-reporter's counter-proposal (which will always be less than or equal to the number specified by the partition). The response parameters are the same as the request parameters. And in addition to the bit indicating that the capability not supported by the hypervisor is off, the capability bit mask will be the same as the mask passed in the request. The hyper-manager will have a maximum of 8 and 1 for the "maximum entry event" and "maximum exit event". If the partition specifies a higher value, the HyperManager will deny this value. If the partition specifies a lower value for some reason, the partition will perform the lower value, but the pipeline volume can be affected by the negative 146527.doc -37- 201102805. An initial value of zero will result in a GenericError. Return code: Pass back in the common header. There is no specific event to return the code. Possible values are: • Good • GenericError Switching capability: This is an LP event interface. The partition and hypervisor exchange capabilities via the LP event interface after the session is started. Unlike the opening period, this command can be sent multiple times during the duration/life of the session. The partition and HYP must support this command as both source and destination. If the ability of the partition or hypervisor changes due to simultaneous firmware/code update, you can use this command to exchange capabilities (assuming non-simultaneous firmware/code updates will cause the session to close and make an open after the update) The meeting will take place). Each of the two entities must verify that their current capabilities have been exchanged with the source whenever they receive a stream that is not a switching capability. If not already exchanged, the ExchangeCapabilities return code must be returned. If an event that changes or may have changed the ability of the target occurs, the target must exchange capabilities with all sources again. Request Parameters · Name Description Event ID Event Code. Number of capability bytes The number of capability bytes below The capability byte Each bit represents a capability. The source initiates a bit indicating its ability to support, and the target closes its bits indicating its unsupported capabilities. Response parameters: 146527.doc -38- 201102805 The response parameters are the same as the request parameters except that the bit indicating that the capability is not supported by the target is off. Return code: Pass back in the common header. No event-specific return code. Possible values are: • Good • GenericError

HypervisorPipeRequestlnbound: This is a LP event interface. The hypervisor streams a hypervisor pipeline to the partition specified as the target of the stream via the LP event interface. From the point of view of the zone, the stream is inbound. This is an asynchronous event. The ACK only acknowledges that the partition received the event and intends to handle the event. In the ACK, only the error that prevents the partition from processing the request should be reported. In other words, if the partition will never process the request due to some invalid command parameters, the partition should ACK the HypervisorPipeRequestlnbound with a bad return code (such as InvalidParms). After the ACK of HypervisorPipeRequestlnbound, the error that occurred when processing the request should be reported back to the source entity via the goods in the hypervisor pipe request event. Request parameters: Name Description Event ID ID Code Source ID Source identifies the size of the goods below the size of the goods (in bits) Group of goods.) Cargo goods 146527.doc •39· 201102805 ack parameters: Name Description Return code See “Return Code” below. Extra return code data length Additional code specific data (if any) The length of the extra return code data is additionally returned to the code specific data (if any). Return code: • Success • Failure • InvalidParms • ExchangeCapabilities • Super Manager Pipe Request This is an LP event interface, and the partition starts a hypervisor pipeline flow as a source of the stream via the LP event interface. From the point of view of the partition area, the stream is out of the way. The hypervisor transports the goods. To the target entity. This is an asynchronous event. The ACK only acknowledges that the hypervisor received the event and intends to forward it to the destination. In the ACK, only errors that prevent the hypervisor from forwarding the request to the destination will be reported. The partition may specify whether to DMA the goods or whether they are included in this event. The partition may decide to only proceed if the goods are too large for the event. DMA or DMA all the time, although the DMA is less efficient than including the goods in the event itself when the goods are small enough to load the event. If DMA is specified ("DMA required" = 1), then The partition must specify a series of logical real address/length pairs that describe the cargo data buffer. Each entry describes a single connected real address range. This range cannot be spread across pages. For example, if the partition is allocated from the system to a cargo buffer with a length of 4000 146527.doc -40·201102805 bytes and spans a page boundary, the partition must be pinned to the storage and in the buffer list. Create two logical real address/length entries. In addition, the partition cannot release the buffer containing the data to be DMA until the hypervisor ACKs the event. Request parameters: Name Description Event ID Event identification - Target ID Target identification Requires DMA 〇 - This event contains goods, 1 = DMA goods must be self-divided ‘ Object size The size of the goods (in units of 兀 group). If the DMAj field is required to be 〇, it should reflect the size of the goods in the cargo block, or if the "Require DMA" field ^ 1 ' should reflect the size of the goods to be DMA" If "Requires DMA" = 0, The maximum cargo size is 176 bytes minus the size of the request parameter (176-16=160). If "Requires DMA" = 1, the maximum cargo size is 1472 bytes. If "DMA is required, =1 ' then the remaining request parameters are as follows: _ buffer list size buffer, size of the monthly order (in bytes). The format of the buffer list is shown below 0 only in "requires DMA" It is valid when set. Buffer list address _·rush = the real address (logically true) of the list in the partition address space. The buffer list must be fixed and reside in the connected real memory. It cannot be spread across pages. The format of the buffer list is shown below. Only if "Requires DMA" is set to be valid, right away from UMA", the remaining request parameters are as follows: Goods/Goods-~~ Buffer List: The buffer list is a series of address/length pairs, where Each pair describes the real buffer space connected by a chunk. If the buffer resides in unconnected real memory, multiple entries are required. Name Description ----- Buffer list size The size of the buffer β (including this rogue) (in the case of a single bite). For each address/length; variable pair, the following ~~~---- address size Ϊ, 疋 real memory in the partition address space real address Λ) 'copy a piece of goods from the address' buffer The device can't be finished. |Field address"^ The size of the buffer "block" of the address (in bytes) 146527.doc -41 - 201102805 ack parameters: Name Description Return code See "Return Code" below. The size of the return data additionally returns the size of the specific data (if any) of the code (in bytes). The extra return code data is additionally returned to the code specific data (if any). Return code: • Success( Success) • Failure • Busy • InvalidParms • PipeClosed • MtuViolation • ExchangeCapabilities • BufferNotPinned • Memory Sue ( MemorySue) The return code LP event return code is the same as the return code used for the HMC command, and is unique to the following LP events.

BufferNotPinned (buffer not fixed) The request was not executed because the buffer specified by the partition from its DMA data or DMA data is not fixed. Recovery: Change the split code to fix the buffer. This is most likely a code error in the partition.

MemorySue (memory Sue) 146527.doc -42- 201102805 The execution is not performed because the memory SUE occurs when accessing the partition memory. Recovery: None. HMC-i5/OS command: This section lists the commands that flow between the HMC and the split zone as goods in the hypervisor pipe stream. It should be noted that the materials in this section provide examples and guidance for those who construct goods that flow through the Super Managed H pipeline. In the following section, the request parameter is a parameter that appears in the cargo field of the super-management sneak flow (source transport primitive) that initiated the request, and the response parameter is a super-management that occurs in the response of the table to the original request. The parameter in the cargo block of the pipe flow (target transfer primitive). Command Category, Command Code: In the command definitions below, the "Command Category" value indicates a specific category of commands, such as all of the commands associated with a particular function (i.e., session management). The "command code" is shown in the category - specific commands. Category values must be unique in all categories. The code value must only be unique within the category. The command code for the response associated with the -specific request is the command code for the request with the higher order bits on it. Switching Capability This is the exchange, through which the two endpoints (source and destination) exchange the ability to define expectations and behaviors related to the duration of the hypervisor pipeline between the two endpoints. The maximum entry/exit can be negotiated based on the needs of the two endpoints. It should be self-requested 146527.doc -43- 201102805, ', the point of view to explain the people / out. The source of the CapabiHties request should be set to the maximum number of requests that can be processed at the same time, and the maximum exit is set to zero. The goal should set its outbound request's 1st schedule 7 to be less than or equal to the maximum outbound value specified by the source. The maximum outbound value is set to the number of simultaneous requests that can be processed. =^ Set the progress of the outbound request to a value less than or equal to the target-maximum exit value. As an example, assume that the maximum entry and = 阜 are negotiated to a value of 4, which means that the HMC can expect the partition to simultaneously 'up to an unprocessed upstream request, and the partition can expect to serve C at the same time. Unprocessed downstream request. If there is a corresponding response stream that has not been received by the source of the requested stream, the request stream is considered unprocessed. In terms of maximum entry/exit, there is no deposit on the generic hypervisor pipeline::: The request stream for the response flow is not considered unprocessed. However, the point does not have the number of unprocessed entries that can be disposed of, and can dynamically allocate internal messages and control blocks to the endpoints instead of pre-allocating the internal messages and control blocks. ), the endpoint may sigh the value of the exchange capacity corresponding to the maximum unprocessed bee that it can support as a non-limiting special value (such as all OxF). Another - end: You can then send the required number of hypervisor pipeline flows to the target without the schedule 1 'but should be prepared for the target may be temporarily unavailable to obtain the necessary > source (such as, from, 4 ^ * heart The condition of the control block space, etc.) comes from the occasional BUSY (passive) return code of the target. Request parameters: 146527.doc 201102805 Name--_ Description of content Command class Command class --- Command code Command code indication ^ —~~ Need to respond to a source that does not expect the source of this stream to be expected from a target response stream . The request ID $1 eye-seeking" super-manager pipeline flow is tied to the corresponding "response" super-fragrance ^· official road flow. The target of the request simply passes the value in the response stream. The source of the request associates the value from the response stream with the corresponding request. The maximum number of incidents in the event. Maximum outbound event The maximum number of unprocessed outbound events. Number of capability bytes The number of bytes below this force Ability ^ 7L is not a capability. The source initiates a _bit indicating its ability to support, and the target closes its bits indicating its unsupported capabilities. Response parameters: Name Description of content - Command category Indicates the command category. Command code Command code indication. Return Code See "Return Code" below. Request ID The request ID value from the associated request. The maximum number of anti-recommendations for the source of the event's target is the maximum number of anti-suggestions of the target's proposed anti-recommendation. The number of the number of bytes below the ability to indicate the ability to be not supported by the target is off. Other than the same in the request parameters. Return code: • Success • Failure • InvalidParms • PresentStateProhibits • Busy cancels the request for this exchange, the source of the previous request stream that has not yet been processed The originator can cancel the request via the exchange. The intent is to use this stream if the request timer maintained by the source/initiator expires or the source is unwilling to see the response for some reason only 146527.doc • 45· 201102805. A positive response (successful return code) from the target of this request means that the target will not send a response stream for the specified request ID' and the specified request ID can be reused by the originator of the request. A negative response from the target (unsuccessful return of the code) means that the originator can still obtain a response stream for the specified request ID and can no longer use the request ID until the response stream is received. Request Parameters·Name ---Content Description _ Command Category -------------- Instructions for the command category. _________ Command code Commander's instructions for today's mother 0 ________r:---r- Requires response Request ID Known-n is tied to Lai." Super-rule ts _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Off: ________ The request ID to be cancelled is associated with the previous request for the previous request for which cancellation is pending. Response parameters: Name Description of content Command category Indicates the command category. Command code Command code indication. Return Code See below for "Return Code" Request ID The request 来自) value from the associated request. The request ID to be canceled is the request ID associated with the previous request for which cancellation is being requested. Return code: 146527.doc -46 - 1

Success • Failure • InvalidParms • PresentStateProhibits • RequestCannotBeCancelled • Busy 201102805 Feature x Request this section to request a fictitious Feature X request The command defines that the fictitious "function X" request is a typical request originating from the hypervisor pipeline flow at the HMC and requires a "pull" method to encapsulate the response data. The request is an upstream stream. The response is a downstream stream. Clearly asked: Command Category Command Code Requires Response Request ID' Additional Resources Additional Resources #Γ _Content Description__ Instructions for the command category. _____ Command code indication. ___________ A bit indicating whether the source of this stream expects a response stream from the target. _ A "request j super manager pipeline flow" to the corresponding "response" hypervisor pipe flow. The target of the request simply passes the value back in the response stream. The source of the request associates the value from the response stream with the corresponding request. __ The size of any additional material associated with this request. ~ Additional information associated with this request. "~~ Response parameter: Name Command category Command code Return code Content description Command category indication Command code indication

Request ID Response Data Index Key Response Data Serial Number Total Response Data Size Responsive Data Size The size of the response data in this command Response Data Return Code: See below "Returning Code from Request ID Value of Associated Request" The target of this response will be returned in the request for the remaining response data, and the source of this response will then use the token to identify what is being requested and where to continue to return the data in the total response data. In the case of the eve, it is a simple token, but it can encode a tuple displacement in a buffer for returning to the source or encode an index into the group for the return of the deer. Il«k T57 Picking Sa B a rir OJ& 2: --------- The total g of the response data of the funeral) This response is the size of the material that is still to be transmitted. The size of the response data^ is included in this back>^ The actual response is 146527.doc •47· 201102805 • Success • Failure • InvalidParms • PresentStateProhibits (current state is prohibited) • ExchangeCapabiliti Es (exchange capability) • Busy (Busy) Retrieve Responsive Data Request This is a request that flows from the endpoint to the other endpoint via the hypervisor pipeline to initiate the transfer of additional response data associated with the earlier request. A per-category command that requires the use of a pull method to encapsulate response data shall define the command code for this command to facilitate the delivery of the request to the appropriate component within the target. Encapsulation of response data can also be achieved by sending multiple response flows (push methods) via the hypervisor pipeline. That is, the target of the request sends multiple responses until there is no more response data. The source of the request (the target of the response) knows when the last response was received because the "Remaining Response Data Size" field is 0. Request Parameters · Name Description - Command Category Indicates the command category. ------ Command code Command code indication. ---- Need to respond Refers to whether the source of this flow is expected to open a response stream from the target. The request ID binds the "request" hypervisor pipeline to the corresponding "response" pipeline flow. The target of the request simply passes the value back in the response stream. The source of the request will come from the value of the response stream and the corresponding request. Relevant. '/ The response data index key comes from the latest response flow related to the data being retrieved. Response parameters: 146527.doc -48- 201102805 Name Description------ Command Category Command Category Indication. ---- Command code command code indication. — Return code ¥ see 1 code below. ------ Clear ID The request ID value from the associated request. - Respond to the data index key ^self' The goal of this response is to return the remaining response data and the source of this response is then used to identify the request and where to continue the data in the total response data. . The 3 2 standard is a simple token, but it can be used in the buffer of the _ byte group source or the index of the index can be used to enter the response data sequence number of f back to f. This value is based on 1 (from the mouth of the pottery test ^ back ^ ^ yellow material size ^ the data taken in response to the remaining response tribute size the size of the response data in this order in this response stream Responding to the big data ---- _______ ^------ - Continuation • Tian pain in the middle 1 --- ------ ^ 151 Zff · Return code: • Success (Success) • Failure ( failure)

InvalidParms (invalid parameter) PresentStateProhibits (current state is prohibited)

ExchangeCapabilities

IrwalidResponseDataKey (invalid response data index key) Busy (busy green) return code

Success

The request was successfully completed. Recovery: N/A -49- 146527.doc 201102805

Failure request failed 'and no other information. Recovery: Retry the request. ^ The problem continues to exist and the standard problem analysis process begins.

InvalidParms The target detects invalid data/parameters in the command (such as unrecognized command categories or command codes). Recovery: None. May be an error.

PresentStateProhibits (current state is disabled) The current state of the target is prohibited from processing this command. Recovery: Puts the target into a state in which it can process the command.

ExchangeCapabilities(^t ^ ^ Λ ) The request was not executed because the ability of the target may have changed since the last exchange capability. Recovery: The source should issue the ExchangeCapabilities command and then retry the request.

InvalidResponseDataKey The request to retrieve additional response data is not processed by the target because the response data index key value provided in the command is not valid. Recovery: None.

RequestCannotBeCancelled The request could not be canceled. The specified request may be in the process of flight, or it may have proceeded to a situation where it is no longer possible to cancel. The response will come. 146527.doc -50· 201102805 Recovery: None.

Busy (busy green) The request was not executed because the request target is busy green. This situation is expected to be temporary. Recovery: After a short delay, retry the program. If the condition persists for an extended period of time (i.e., several minutes), there may be an error in the target and contact IBM Technical Maintenance. Design Details · Command Flow Control and Adjustment Progress Partition - HYP LP Event Session HYP must provide an ACK message for each HypervisorPipeRequestlnbound sent to the partition. HYP maintains a separate pre-allocated message pool for each partition that is actually present (rather than the largest architectural partition). When a partition is created or deleted, its message set and message will also be created and deleted. Each partition has a separate pool along with an immediate upstream ACK to the upstream stream with a target of the empty message set to prevent the partition of the un-timed ACK event from affecting the throughput of the other partitions. An acknowledgment of an upstream request for a partition from which the HMC to ACK message pool is empty in a busy state places a temporary busy period in the target partition and a permanent unresponsive burden on the HMC. The HMC shall treat a Busy return code as a temporary condition and periodically retry the upstream request until it is active or a reasonable amount of time has passed and is still busy (in this case, the HMC can assume that the target is not reaction). Reception of ACKs from partitions will not be clocked by HYP. The 146527.doc -51 - 201102805 ACK request partition may or may not be receiving a new request, so the ACK message is released by timeout so that the extra request can be sent. 0 HYP will signal The hypervisor pipe request event is sent asynchronously to the partition. This means that the HYP task is not blocked before receiving the ACK, and for partitions, multiple events can be unprocessed at the same time. Since the number of unprocessable events is limited by the number of ACK messages in the pool, the HYP will be consistent with any maximum entry value suggested by the partition equal to or less than the number of pre-allocated messages for each partition. If the partition suggests a larger value, HYP will reduce the number to the configured number in the open session response. The HYP will adjust the progress of the upstream request transmission to the partition so that the negotiated maximum entry value is never exceeded. HYP will always set the maximum exit value to 1 in the open session response, because HYP will be single-threaded during processing of the upstream hypervisor pipe request flow from the partition, thereby making it larger than The value of 1 is meaningless. The partition should be ACKed as soon as possible so that the ACK message will be quickly passed back to the appropriate pool in the HYP. This will maximize the amount of pipe delivery. The longer it takes for the ACK to enter the turbulence, the greater the chance that the ACK message set will be exhausted. When exhausted, HYP will begin to request the source ACK with a lethargic partition in a busy state. Restarting a partition that is unresponsive and does not ACK upstream requests will force all unprocessed ACK messages back to HYP. HMC-HYP Command Session The HYP treatment for the session between HMC and HYP is similar to the treatment for the session between the partition and HYP as described in the previous section 146527.doc -52- 201102805. HYP must provide an ACK message for each Hypervisor Pipeline Request command sent to the HMC. HYP will maintain a message pool for each HMC connected. Each HMC has a separate pool and ACKs to the downstream stream of the target HMC with the empty message set immediately with the busy state to prevent the HMC of an unacknowledged ACK event from affecting the throughput of the other HMCs. The downstream request of the HMC with the busy status ACK from the partition to the ACK message set area will place the temporary busy time period and the permanent non-responsive burden in the disposal target HMC on the partition. The partition should treat a Busy return code as a temporary condition and periodically retry the downstream request until it is active or a reasonable amount of time has passed and is still busy (in this case, the partition can be assumed The target is not responding). The HYP will adjust the progress of the downstream request transmission to the HMC so as to never exceed the negotiated maximum entry value of the given HMC, which will be negotiated as the maximum value (for example) 8 (if the HMC initial recommendation one) A value less than 8, then HYP will perform a lower value). HYP will always set the maximum outbound value to 1 in the open session response, because HYP will be single-threaded during processing of the upstream hypervisor pipe request command stream from the HMC, thereby making the value greater than 1. Meaningless. Reception of ACKs from the HMC will not be timed by HYP. An HMC that is not a positive ACK request may or may not be receiving a new request, so releasing the ACK message by timeout may make it possible to send an additional request.

The HMC shall ACK into the turbulence as soon as possible so that the ACK message will be quickly transmitted back to the appropriate pool in the HYP. This will maximize the amount of pipe delivery. HMC 146527.doc 53· 201102805 The longer it takes for the ACK to enter the turbulence, the greater the chance that the ack message pool will be exhausted. When the acknowledgment is exhausted, HYP will start to use the busy state to request the source ACK to slumber the HMC. Restarting or disconnecting an HMC that is unresponsive and does not ACK downstream requests will force all unprocessed ACK messages back to HYP. HMC-Segmentation Period The duration described above includes a higher level period between endpoints (HMCs and partitions) and manages and controls these periods in much the same way as the base period. Capability exchange allows two endpoints to negotiate maximum entry/exit values and determine support for each other's specific capabilities defined in the capability byte. In order to prevent the two endpoints of the hypervisor pipeline from being out of sync in terms of capabilities and/or maximum entry/exit, the destination of any hypervisor pipeline flow that is not an ExchangeCapabilities command must be checked from the destination. The event experiences an event that may have changed its capabilities (such as IPL, during which application code updates, or firmware updates) to see if the source has exchanged capabilities with the destination. If not, the destination must return an ExchangeCapabilities return code in the response stream. When the source of the request receives the ExchangeCapabilities return code, it must send an Exchange CapabUities command to the destination and then resend the original request that failed. The maximum entry/exit can be negotiated based on the needs of the two endpoints. Interpretation/exit should be based on the source of the request. The source of ExchangeCapabilities should be set to the maximum number of requests that can be processed at the same time 146527.doc •54- 201102805, and the maximum will be adjusted..., the target should be sent out of the request The threshold of the gold retreat is less than or equal to the value, and the maximum value of the depreciation is determined. The maximum value of the depreciation is determined by the number of requests that can be processed at the same time. The maximum specified exit value of the target is set to be less than or equal to the value of 4 for both the target and the exit. This example is assumed to be the maximum entry, and + this means that the HMC can expect the partition to be supported at the same time. Up to 4 unprocessed above J卞夂4. ^ ^ ^ °, and / knife cutting zone can expect HMC to support 4 unprocessed A at the same time, „ 荇 求. Unprocessed means request flow The source does not receive the corresponding response stream from the source. If the endpoint does not have an identifiable limit on the number of unhandled persons it can handle (such as dynamically assigning internal messages and control blocks to the endpoint) t: the condition of the internal message and the control block of the knife, and the value of the maximum unprocessed person in the force of the end of the Z-month change is specified as a private unrestricted special Value (such as all 〇xF) ^Another endpoint can send its required number of super-processed f-channel streams to his target without adjusting the progress' but should be prepared for disposal because the target may not be able to obtain the necessary source of education temporarily ( The status of the message, control block space, etc., comes from the occasional Busy (passive) return code of the target. It should be noted that 'obeying the maximum entry/exit value negotiated between the HMC and the partition does not guarantee that the source of the request stream at this session avoids the Busy (busy) return code. If the target ACK message area If it is empty, the Busy (busy) return code can be generated by HYP in the HypervisorPipeReqUes request message stream ACK. Detection 146527.doc •55· 201102805 Η Υ P should provide a certain amount of detection to track such as generated The busy A c κ and the number of target endpoints, the number of failed transmissions, the average amount of time in the pipeline (for both upstream and downstream), the total number of upstream and downstream flows, and so on.

Busy Return Code Handling The recommendation to busy return code from HYP in the endpoint is to retry the turbulence after a short delay and repeat until a reasonable amount of time has elapsed or the turbulence last succeeded. A reasonable amount can be based on the command or request being sent. 0 Exchange Capability Disposition The recommendation to return the ExchangeCapabiUties (replacement capability) code from HYP or other endpoints is to issue ExchangeCapabUities (Exchange Capability). Request for the month and then retry the rejected request. Alternatively, the endpoint may choose to issue an Exchange Capabilities request and abort rather than retry the rejected request. The user will then have to manually retry the failed request. This alternative can be attractive in situations where it is difficult to automatically retry a failed request. If this alternative is implemented, it should be known that although the capability change is rare, the split/power down/power-on can occur relatively frequently and will cause the partition to return the EXChangeCapabilities (return capability) return code (until again with the source of the request) /Starting party exchange ability). (d), measures can be taken to reduce the possibility of ExchangeCapabilities (return capability) return codes. One of the endpoint implementations (Option D is to publish ExchangeCapabUities requests to all roles whenever an event that may have changed capabilities (such as 'simultaneous code update (or removal) or endpoint power up) occurs 146527.doc •56· 201102805 endpoint. By doing so, the endpoint caches all other possible endpoints and notifies the other endpoints by something that may change the capabilities of the other endpoints. To maintain the ability of the cache to be current. This method does not completely prevent ExChangeCapabilities (transfer capability) transmission (four) because in the exchange capacity _, the stream may be in the process of transmission, but it will indeed return ExchangeCapabiHties (exchange capability) The chance of the code is reduced to a low enough level to make the request to abort the rejection (rather than the automatic retry of the rejected request) will be an acceptable option. The reduced ExChangeCapabilities in the endpoint will occur. Another implementation of the possibility (option 2) is to issue an EXChangeCapabilities request to the endpoint before each request. 'Do not have the ability to cache. Just query the ability when needed. As with option 1, this method does not completely eliminate the possibility of getting the ExchangeCapabimies (switching ability) to return the code, but it reduces the chance to a low enough level to stop being Requests for rejection (rather than automatic retry) will be acceptable. It should be noted that this method may significantly increase the number of flows between endpoints. In the simplest form, it will double the number of streams to 4 - a specific user task for a particular endpoint to complete a task, the originating endpoint may publish ExchangeCapabilities to the target endpoint once per user task (rather than once per request stream). This reduces the total number of ExchangeCapabilities flows. For the two options described above, each endpoint must track the other endpoints with which it has exchanged capabilities, and for which it is not the ability to exchange First-class and verify that it has exchanged its current capabilities with the source of the stream. If a change is made 146527.doc -57- 201102805 or an event that may have changed its capabilities If it is born, it must exchange its new capabilities or potential new capabilities with other endpoints. Whenever an event that may change the capabilities of HYP (ie, simultaneous firmware update) occurs, HYP will be generic in all roles. The Manager Pipeline HMC Session and the LP Event Session start an ExchangeCapabilities request. Similarly, whenever an event that may change the capabilities of the endpoint (ie, simultaneous code update) occurs, the endpoint The point should initiate an Exchange Capabilities request for HYP. Therefore, the endpoint must support the Exchange Capabilities flow with HYP as both the source (i.e., when the endpoint is subject to simultaneous code update) and the target (i.e., when the HYP is undergoing simultaneous firmware updates). The ability to exchange when the HMC or partition is powered on via the open session command. Further details regarding the shared memory partition data processing system are provided in the following co-pending patent application, the entire contents of each of which are hereby incorporated by reference herein in (Agent Case No. ROC 920080415US1), "Hypervisor Page Fault Processing in a Shared Memory

Partition Data Processing System; US No. _ (agent case number ROC 920080416US1), "Managing Assignment of Partition Services to Virtual Input/Output

Adapters; US No. - (No. ROC 920080417US1), "Automated Paging Device Management in a Shared Memory Partition Data Processing System"; US No. (Agent Case No. ROC 920080418US1), 146527.doc -58 - 201102805 ".Dynamic Control of Partition Memory Affinity in a Shared Memory Partition Data Processing System"; US No. (Agent No. ROC 920080419USI), "Transparent Hypervisor Pinning of Critical Memory Areas in a Shared Memory Partition Data Processing System" ; US __ (agent case number ROC 920080420US1), "Shared Memory Partition Data Processing System with

Hypervisor Managed Paging"; US No. _ (Agent Case No. ROC 920080421US1), "Controlled Shut-Down of Partitions Within a Shared Memory Partition Data

Processing System"; and US No. _ (agent case number ROC 920080422US1), "Managing Migration of a Shared

One or more aspects of the present invention can be included in an article (e.g., one or more computer program products) having, for example, computer usable media. The media has, among other things, computer readable code components or logic (e.g., instructions, program code, commands, etc.) to provide and facilitate the capabilities of the present invention. The article can be included as part of a computer system or sold separately. An example of an article or computer program product having one or more aspects of the present invention is described with reference to FIG. The computer program product 1400 includes, for example, one or more computer readable media 1410 for storing computer readable code components or logic 1420 thereon to provide and facilitate the present invention. One or more aspects. The media can be electronic, magnetic, optical, 146527.doc -59- 201102805 electromagnetic, infrared or semiconductor systems (or devices or devices) or propagating media. Examples of computer readable media include semiconductor or solid state memory, magnetic tape, removable computer magnetic disks, random access memory (ram), read only memory (job), hard disk and optical disk. Examples of optical disks include Compact Disc Read Only Memory (CD-ROM), Compact Disc Read/Write (CD R/W) & dvd. The execution of aspects of the present invention is directed to a sequence of program instructions or sequences of logic modules defined by - or a plurality of computer readable programs (s) or logic. Various embodiments are described above, but such embodiments are merely examples. This environment may include a simulator (example >, software or other analog phase = its \ analog - specific architecture or a subset thereof. In this environment, the simulation enables the simulation function to implement the invention - or multiple states The same is true, that is, the computer architecture of the emulator is also the same. As the ^^4T emulation mode with different capabilities than (4), the special emulation 7 or operation of the simulation is decoded, and the instruction or operation# Build-appropriate simulation function to implement an in-simulation environment, the host computer is used to store instructions and data; _ command to raise the body's fetch instruction ^ early, which is used to self-memory...Μ to provide The local buffer of the extracted instruction. The heart decoding unit, the type of the instruction that is extracted by the heart; and the instruction: the instruction of the single: used to determine the order. The execution may include: performing the data self-discipline Refer to the storage " store to return to the memory; load = save ... will be *-type arithmetic or logical operation. In the solution of the unit determination, software 146527.doc 201102805 each unit. For example The operations that will be performed by these units One or more secondary routines. Alternatively, a data processing system suitable for storing and/or executing code may be used, including at least a processor that is indirectly connected to the memory component either directly or via a system bus. The memory component includes, for example, a local memory, a large-capacity memory, and a cache memory used during actual execution of the code, and the cache memory provides temporary storage of at least some code to reduce The number of times the code must be retrieved from the mass storage device during execution. Input/rounding or I/O devices (including (but limited to) keyboard devices, (10)D, tape, CD, DVD, flash drive, and other media The system can be coupled to the system either directly or via intervention y. The network can be coupled to the system to enable the data processing system to be tapped to other data processing systems or remote printers or via the intervening public network. A few of the data adapters and types of network adapters. 卞 Only for the present invention - or a plurality of states - a combination of ~ force 7 for rolling, body, hardware or storage Device, its materialization In the case where at least one of the program storage instructions can be read by the machine to perform the present invention, the flowchart depicted in this document can be used only in the case of God. Without departing from the essence of the present invention Many changes in operation). For example, the steps claimed in the steps may be performed in a different order, such as a clear, delete, or modification step. All such changes are considered to be part of the invention of the king. 146527.doc -61 - 201102805 Although the embodiments have been described in detail and described in detail herein, it will be apparent to those skilled in the art that Emotions/brothers make various modifications, annihilation, J' substitutions and the like, and therefore, these modifications, additions, and substitutions are considered to be 1 #5 y, & The scope of the invention as defined in the scope of the patent. [Brief Description] FIG. 2 is a high level block diagram of various hardware components of a logically segmented data processing system in accordance with an aspect of the present invention; FIG. Conceptual illustration of logical partitions at different hardware and software abstraction levels in a data processing system; FIG. 3 is a logic diagram of a hypervisor-based communication facility in accordance with aspects of the present invention; Segmented data processing system - block diagram illustration of an entity embodiment; FIG. 4 is a lower level logical view of the data processing system and communication facility of FIG. 3 in accordance with an aspect of the present invention, wherein the communication session is established between the HMC and the super-managed pipe. And between the logical partition and the hypervisor pipeline; a higher level logical depiction of the hypervisor-based communication facility of FIGS. 3 and 4 in accordance with aspects of the present invention; FIG. 6 is a diagram in accordance with the present invention. A flowchart of an embodiment of hypervisor logic for processing communications received by a source endpoint of a logically segmented data processing system; FIG. 7 is a diagram of a hypervisor in accordance with aspects of the present invention. A flowchart of an embodiment of a logic for processing a general-purpose communication primitive (Hypepipe); FIG. 8 is a diagram of a material processing system for processing logical segmentation according to aspects of the present invention; 146527.doc • 62-201102805 A flowchart of an embodiment of a hypervisor logic for an acknowledgement (ACK) received by an endpoint; FIG. 9 is a diagram for constructing an exchange capabimies request and transmitting it to the aspect of the present invention Logical division A flowchart of an embodiment of hypervisor logic for a target endpoint of a cut data processing system; FIG. 10 is a logically partitioned data processing in response to an event that may cause a hypervisor capability change in accordance with an aspect of the present invention; A flowchart of an embodiment of hypervisor logic executing when occurring within a system; FIG. 11 is a diagram of processing a target transport primitive at a target endpoint of a logically partitioned data processing system in accordance with an aspect of the present invention; A flowchart of an embodiment of point logic; FIG. 12 is a flow diagram of an embodiment of endpoint logic for actively initiating an exchange capabilities request from an endpoint in accordance with an aspect of the present invention; 13 is a flow diagram of an embodiment of endpoint logic for passively performing capability exchange in response to a capability change event at an endpoint of a communication facility in accordance with aspects of the present invention; and FIG. 14 depicts and incorporates the present invention An embodiment of one or more aspects of a computer program product. [Main component symbol description] 100 101 102 103 Computer system central processing unit (CPU) which can be logically divided Main memory service processor 146527.doc -63- 201102805 105 Bus 86 Terminal interface 107 Memory interface 108 Other I /O device interface 109 communication / network interface 111 Α, 111 Β, 111C ' 111D circuit card 112A, 112B, 112C, 112D, 112E, 112F circuit card 113 circuit card 114 hardware management console (HMC) 115A, 115B, 115C circuit Cards 116A, 116B, 116C Circuit cards 117A, 117B Circuit cards 118A, 118B Circuit cards 119A, 119B Circuit cards 121A, 121B, 121C User terminals 122A, 122B, 122C Data storage device 123 Printer · 64 · 146527.doc 201102805 124 Fax machine 126 Network 201 Hardware level 202 Non-dispatchable hypervisor 203 Distributable hypervisor 204 Logical partition 205 Logical partition 206 Logical partition 207 Logical partition 211 OS core 212 OS core 213 OS core 214 OS Core 221 visual indicator 222 assignable to partitionable entity 223 separable physical location 300 logically partitioned data processing system 310 logical partition 320 hypervisor 325 hypervisor pipeline 330 flexible service processor 340 hardware management console (HMC) 400 logical HMC command session / HMC to hypervisor session 146527 .doc •65- 201102805 405 Message Buffer Pool 410 Logical Split Event Session/Logical Split to HyperManager Session 415 Message Buffer Set 500 Logical HMC Pair Partition Communication Session 1400 Computer Program Product 1410 Computer Available Read media 1420 computer readable code component or logic 146527.doc -66-

Claims (1)

201102805 VII. Patent application scope: 1 · A method for communication between a hardware management console and a logical partition of a logically divided data processing system, the method comprising: the source endpoint being A request or a response is packaged as a commodity in a general-purpose transport primitive, the source endpoint being one of a hardware management console or a logical partition of the data processing system, wherein the hardware management console a user interface for partition management; and forwarding the generic transport primitive from the source endpoint to a target endpoint via a hypervisor of the data processing system, wherein the hypervisor receives The generalized transport primitive encapsulated by the source endpoint and the goods of the generic transport primitive are forwarded to the target endpoint, the shipment containing the request or the response of the source endpoint, and wherein The super-manager performs the inspection and parsing of the goods by the hyper-manager in the receiving and the transfer, and the target endpoint is the logical partition of the data processing system or the hardware management console The other one. 2. The method of claim 1, wherein the received generalized transport primitive is a source transport primitive 'and wherein the forwarding comprises constructing a target transport primitive by the hypervisor, the The goods of the source transport primitive are copied into the target transport primitive and the target transport primitive is forwarded from the hypervisor to the target endpoint. 3. The method of claim 2, wherein the receiving comprises receiving, at the hypervisor, the source transport primitive into a receive buffer, and the constructing comprises at the super processor a target message The target transport primitive is built in the buffer. The target message buffer is from one of the message buffers associated with the endpoint of the destination 146527.doc 201102805 at the hypervisor (p〇〇l ). "A method of claim 3, wherein the constructing further comprises determining whether a target message buffer is available in the set of message buffers associated with the target endpoint, and if so, from the target endpoint The pool of associated message buffers obtains the target message buffer and constructs the target transport primitive in the obtained target message buffer, the build containing the source endpoint to be included by the hypervisor The request or the response of the goods is copied from the receiving buffer to the target message buffer without checking or dissecting the goods. 5. The method of claim 2, wherein the target transfer primitive is transferred Delivering to the target endpoint includes asynchronously forwarding the target transport primitive to the target endpoint. 6. The method of claim 2, wherein the constructing comprises verifying, by the hypervisor, the source transport primitive The size of the goods is within an acceptable size range, and verification is determined by the target endpoint provided by the source transport primitive. 7. The method of claim 2, wherein the target endpoint is receiving The head Determining whether the shipment contains a valid request after the primitive is transmitted, and if so, processing the request and transmitting a response via the hypervisor to the source endpoint as another generalized transport primitive, and if With the target transmitting primitive - the received payload is not a valid request, the point determines whether the shipment contains a valid response, and if so, the response. 8. The method of requesting, further comprising: enabling a communication session between the hardware management control 146527.doc 201102805 and the hypervisor, and enabling a connection between the logical partition and the hypervisor The communication session, wherein the opening of the communication session occurs before the encapsulation of the general purpose transport primitive and the transfer. 9. The method of claim 8, wherein the further includes an event in response to changing the capability at the hypervisor or an endpoint of the logically segmented data processing system in the logical partition, the hypervisor And automatically exchange communication capability between the hardware management console, the endpoint is one of the logical partition or the hardware management console, wherein the logical partition and the hardware management console exchange capability Including the L of the following: (1) At the logical partition, the exchange capability is requested to be packaged in a general-purpose transport base, and the general-purpose transport base is self-managed via the hypervisor. The logical partition is forwarded to the hardware management console without the inspection or profiling of the goods by the hyper-manufacturer; or (9) initiated by the hyper-manager-exchange capability request, and the communication request is from The hypervisor is forwarded to the logical partition. , month b 10. A logically segmented data processing system comprising: at least a processor 'which contains at least a logical partition; to; a hardware administrative console, each hardware management console partition management a user interface; and; a super-orientation device that connects the at least one hardware management console to the hobby-to-one (four) interface, and includes the at least-hardware management console via the hyper-management And a communication facility between the at least _ logical partition 146527.doc 201102805, the communication comprising: including, by a source endpoint, the request or a response of the source endpoint as a commodity in a general-purpose transport primitive The source endpoint is a hardware management console of the at least one hardware management console or one of the at least one logical partition; and the generic transport primitive is from the hypervisor via the hypervisor The source endpoint forwards to a target endpoint, wherein the hypervisor receives the generalized transport primitive encapsulated at the source endpoint and forwards the shipment of the generic transport primitive to the target endpoint , the goods contain the request Or the response, and wherein the shipment is not verified or parsed by the hypervisor in the receiving and the transfer by the hypervisor, and the target endpoint is the one of the at least one logical partition The logical partition or the other of the hardware management consoles in the at least one hardware management console. 11. The data processing system of claim 10, wherein the received generalized transport primitive is a source transport primitive, and wherein the transferring includes constructing a target transport primitive by the hypervisor The constructing includes copying the goods of the source transport primitive into the target transport primitive and forwarding the target transport primitive from the hypervisor to the target endpoint. 12. The logically segmented data processing system of claim 1; wherein the hypervisor further comprises a pool of message buffers associated with the target endpoint, and wherein the hypervisor transmits the generic The primitive is received into a receive buffer and the target transport base is built in a target message buffer, and the target message buffer is configured as a message buffer from the target buffer associated with the target endpoint. Get one of the message buffers. 146527.doc 201102805 13. The data processing system of claim 12, wherein the constructing the target transport primitive further comprises determining whether there is one of the regions of the message buffer associated with the target endpoint a target message buffer is available, and if so, the target message buffer is obtained from the pool of message buffers associated with the target endpoint and the target transport primitive is built in the obtained target message buffer The constructing includes copying, by the hypervisor, the request including the edge source endpoint or the response to the goods from the receiving buffer to the target message buffer without inspecting or parsing the goods. 14. The data processing system of claim 11, wherein the forwarding of the target transport base to the target endpoint comprises asynchronously forwarding the target transport primitive to the target endpoint by the hypervisor . 15. The data processing system of claim 1, wherein the at least one processor comprises a plurality of logical partitions, and wherein the at least one hardware management console is coupled to the hypervisor - flexible The service processor is coupled to the hypervisor of the logically partitioned data processing system, and the communication facility is further included between each hardware management console in the at least one hardware management console and the hypervisor Each of the plurality of logical partitions and each of the plurality of logical partitions and the hypervisor open a communication session. 16. The logically segmented data processing system of claim 15, wherein the communication delta history is configured to respond to changing capabilities at the super-orientator or an endpoint of the logically-divided data processing system. An event in one of the logical partitions, the hypervisor, and the at least one hardware management console 146527.doc 201102805 zone one of the logical hardware management controls the automatic switching capability, the endpoint is the multiple logic Split the partition or the at least one of the hardware management consoles. 17. A device having at least a computer readable medium having a data processing means for facilitating logical segmentation, and a management console and a logical partition, the package having at least a computer readable medium - Computer-readable code logic for communication between a hardware management console and a logical communication system, which is readable by the computer. The code logic performs the following actions: The source endpoint's request or 1 should be encapsulated in a generic transport primitive by the source endpoint, which is one of the data processing system hardware management consoles. Or a logical partition, wherein the hardware management console is a user interface for split management; and the general transfer primitive is from the source J via one of the data processing systems. And the point is forwarded to a target endpoint, wherein the hypervisor receives the generalized transport primitive encapsulated at the source endpoint and forwards the goods of the generic transport primitive to the target endpoint, The goods contain the source endpoint The request or the response, and wherein the shipment is not verified or parsed by the hypervisor in the receipt and the transfer by the hypervisor and the target endpoint is the logic of the data processing system The partition or the other of the hardware management consoles. 18. The article of claim 17, wherein the received general-purpose transport primitive is a 146527.doc 201102805 source transport primitive, and wherein the transfer includes constructing a target transport primitive by the hypervisor, The constructing includes copying the shipment of the source transport primitive into the target transport primitive and forwarding the target transport primitive from the hypervisor to the target endpoint. 19. 20. The article of claim 18, wherein the receiving comprises receiving the source transport primitive into a receive buffer at the hypervisor, and the constructing is included in the "Haifu processor The target transport base 70 is built into a target message buffer from a set of regions of the message buffer associated with the target endpoint at the hypervisor. An article of claim 19, wherein the constructing further comprises determining whether a target buffer is available in the region of the message buffer associated with the target endpoint, and if yes, then the target endpoint The set of associated message buffers (4) obtains the target message buffer and constructs the target transport primitive in the obtained target message buffer, the build containing the source endpoint to be included by the hypervisor The request or the item of the response is copied from the receiving buffer to the directory message buffer without checking or parsing the item. 146527.doc