diff --git a/LoPAR/app_bibliography.xml b/LoPAR/app_bibliography.xml index eae8f8f..40257e3 100644 --- a/LoPAR/app_bibliography.xml +++ b/LoPAR/app_bibliography.xml @@ -1,6 +1,6 @@ + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en" + xml:id="app_coherent_platform_facility_error_handling_recovery"> Coherent Platform Facility Error Handling and Recovery During the course of operation, a coherent platform function can encounter errors. diff --git a/LoPAR/app_cmo_def.xml b/LoPAR/app_cmo_def.xml index 6dd2806..5597dac 100644 --- a/LoPAR/app_cmo_def.xml +++ b/LoPAR/app_cmo_def.xml @@ -1,6 +1,6 @@ + xmlns:xl="http://www.w3.org/1999/xlink" + xml:id="dbdoclet.50569381_46906" + version="5.0" + xml:lang="en"> EEH Error Processing - This appendix describes the architectural intent for EEH error processing. - This appendix does not attempt to illustrate all possible scenarios, and other + This appendix describes the architectural intent for EEH error processing. + This appendix does not attempt to illustrate all possible scenarios, and other implementations are possible.
General Scenarios - In general, the device driver recovery consists of issuing an - ibm,read-slot-reset-state2 call prior to doing any recovery - to determine if (1) the IOA is in the MMIO Stopped and DMA Stopped state (that is, - that an error has occurred which has put it into this state), and (2) whether or - not the PE has been reset by the platform in the process of entering the MMIO + In general, the device driver recovery consists of issuing an + ibm,read-slot-reset-state2 call prior to doing any recovery + to determine if (1) the IOA is in the MMIO Stopped and DMA Stopped state (that is, + that an error has occurred which has put it into this state), and (2) whether or + not the PE has been reset by the platform in the process of entering the MMIO Stopped and DMA Stopped state, and then doing one of the following: - + Simplest approach: - + Reset the PE - + Reconfigure the PE - + Most general approach (detailed more in ): - + Release the PE for Load /Store - + Issue Load / Store instructions t o get any desired state information from the IOA - + - Call the ibm,slot-error-detail RTAS call to get the + Call the ibm,slot-error-detail RTAS call to get the platform error information - + Log the error information - + Reset the PE - + Reconfigure the PE - + Most robust (no reset unless necessary): - + Release the PE for Load /Store - + - Issue Load / Store instructions + Issue Load / Store instructions to get any desired state information from the IOA - + - Call the ibm,slot-error-detail RTAS call to get the + Call the ibm,slot-error-detail RTAS call to get the platform error information - + Log the error information - + Device driver does IOA cleanup - + Release the PE for DMA and restart operations (no reset) - + - + - In any scenario, after several retries of a recoverable operation, the OS - may determine that further recovery efforts should cease. In such a case, - calling ibm,slot-error-detail with Function 2 - (Permanent Error), in addition to returning error information, marks that the PE is + In any scenario, after several retries of a recoverable operation, the OS + may determine that further recovery efforts should cease. In such a case, + calling ibm,slot-error-detail with Function 2 + (Permanent Error), in addition to returning error information, marks that the PE is no longer accessible due to previous errors.
More Detail on the Most General Approach - The following gives a more detailed look at scenario # - in . This will be broken up into two groups of operations: + The following gives a more detailed look at scenario # + in . This will be broken up into two groups of operations: error logging and error recovery. These scenarios assume that: - + The ibm,configure-pe RTAS call is implemented. @@ -118,18 +135,18 @@ xml:lang="en"> The attempts at recovery stop when Max_Retries_Exceeded is true. - +
Error Logging - + - If the device driver is going to capture internal IOA-specific information - as a part of the error logging process or if the IOA controlled by the device driver - requires a longer wait after reset than the normal PCI specified minimum wait time, - then the device driver determines whether its IOA has been reset as a result of entering - EEH Stopped State, by looking at the PE Recovery Info output of + If the device driver is going to capture internal IOA-specific information + as a part of the error logging process or if the IOA controlled by the device driver + requires a longer wait after reset than the normal PCI specified minimum wait time, + then the device driver determines whether its IOA has been reset as a result of entering + EEH Stopped State, by looking at the PE Recovery Info output of the ibm,read-slot-reset-state2 RTAS call. @@ -138,106 +155,106 @@ xml:lang="en"> - If the IOA requires longer wait after reset times than the specified minimum, - and the PE was reset (see step #1) as a result of the EEH event, then wait the + If the IOA requires longer wait after reset times than the specified minimum, + and the PE was reset (see step #1) as a result of the EEH event, then wait the additional necessary time before continuing. - The OS or device driver - enables PE MMIOs by calling the ibm,set-eeh-option RTAS call + The OS or device driver + enables PE MMIOs by calling the ibm,set-eeh-option RTAS call with Function 2. The OS or device driver calls the ibm,configure-pe RTAS call. - + - If the PCI fabric does not need configuring (the PE was not reset previous to the - call or was reset but was previously configured with ibm,configure-pe ), - then the call returns without doing anything, otherwise it attempts to configure + If the PCI fabric does not need configuring (the PE was not reset previous to the + call or was reset but was previously configured with ibm,configure-pe ), + then the call returns without doing anything, otherwise it attempts to configure the fabric up to but not including the endpoint IOA configuration registers. - If an EEH event occurs as a result of probing during the - ibm,configure-pe RTAS call that results in a - reset of the PE, the PE will be returned in the PE state of 2. Software - does not necessarily need to check this on return from the call. The case - where this occurs is expected to be rare, and probably signals a non-transient error. - In this case the software can continue on with the recovery phase of the EEH processing, + If an EEH event occurs as a result of probing during the + ibm,configure-pe RTAS call that results in a + reset of the PE, the PE will be returned in the PE state of 2. Software + does not necessarily need to check this on return from the call. The case + where this occurs is expected to be rare, and probably signals a non-transient error. + In this case the software can continue on with the recovery phase of the EEH processing, and will eventually hit the same EEH event on further processing. - + - If the PE was - reset (see step #1) as a result of the EEH event, then if the device driver is - going to gather IOA-specific information for logging, it needs to finish the - configuration of the IOA PCI configuration registers, by restoring the PCI - configuration space registers of the IOA(s) in the PE (for example, BARs, + If the PE was + reset (see step #1) as a result of the EEH event, then if the device driver is + going to gather IOA-specific information for logging, it needs to finish the + configuration of the IOA PCI configuration registers, by restoring the PCI + configuration space registers of the IOA(s) in the PE (for example, BARs, Memory Space Enable, etc.). - If desired, the + If desired, the device driver gathers IOA-specific information via MMIOs, by doing MMIOs to its IOA. - The OS or device driver calls ibm,slot-error-detail . - Any data captured in step # is passed in the - call. Note that maximum amount of data will be captured in some cases only when the - ibm,slot-error-detail call is made with PE not in the MMIO Stopped + The OS or device driver calls ibm,slot-error-detail . + Any data captured in step # is passed in the + call. Note that maximum amount of data will be captured in some cases only when the + ibm,slot-error-detail call is made with PE not in the MMIO Stopped State (as it should be in step #). - + - If Max_Retries_Exceeded is true, then call ibm,slot-error-detail + If Max_Retries_Exceeded is true, then call ibm,slot-error-detail with Function 2 (Permanent Error). - If Max_Retries_Exceeded is not true, then call ibm,slot-error-detail + If Max_Retries_Exceeded is not true, then call ibm,slot-error-detail with Function 1(Temporary Error). - + - The ibm,slot-error-detail RTAS call captures whatever - PCI config space registers it can between the configuration address passed in the call - and the system (PHB), and including at the configuration address and at the PHB, and - returns them along with the device specific data in an error log in the return information - from the call. This call may encounter another EEH event, in which case it returns what + The ibm,slot-error-detail RTAS call captures whatever + PCI config space registers it can between the configuration address passed in the call + and the system (PHB), and including at the configuration address and at the PHB, and + returns them along with the device specific data in an error log in the return information + from the call. This call may encounter another EEH event, in which case it returns what information it can in the call, with a Status of 0 (Success). - The OS or device driver logs the log entry returned from the + The OS or device driver logs the log entry returned from the ibm,slot-error-detail RTAS call. - If Max_Retries_Exceeded is not true, then the next step is PE Recovery, + If Max_Retries_Exceeded is not true, then the next step is PE Recovery, otherwise stop and mark the IOA(s) in the PE as unusable. - +
PE Recovery - + - OS or device driver does a PE reset sequence. Note that this step is - required even if the PE was reset as a result of the initial EEH event, because - the error logging steps (for example, the ibm,configure-pe - or ibm,slot-error-detail calls) could have encountered + OS or device driver does a PE reset sequence. Note that this step is + required even if the PE was reset as a result of the initial EEH event, because + the error logging steps (for example, the ibm,configure-pe + or ibm,slot-error-detail calls) could have encountered another EEH event. - + - The device driver or OS calls ibm,set-slot-reset with + The device driver or OS calls ibm,set-slot-reset with Function 1 or 3 to activate the reset. @@ -246,26 +263,26 @@ xml:lang="en"> - The device driver or OS calls ibm,set-slot-reset with + The device driver or OS calls ibm,set-slot-reset with Function 0 to deactivate the reset. - The minimum reset inactive to first configuration cycles is waited. - If the IOA requires more than the standard PCI specified time, then wait that + The minimum reset inactive to first configuration cycles is waited. + If the IOA requires more than the standard PCI specified time, then wait that longer time, instead. - + The OS or device driver calls ibm,configure-pe. - If an EEH event occurs as a result of probing - during the ibm,configure-pe RTAS call that results in a reset - of the PE, the PE will be returned in the PE state of 2. Software does not necessarily - need to check this on return from the call. The case where this occurs is expected to - be rare, and probably signals a non-transient error. In this case the software can - continue on with the recovery phase of the EEH processing, and will eventually hit + If an EEH event occurs as a result of probing + during the ibm,configure-pe RTAS call that results in a reset + of the PE, the PE will be returned in the PE state of 2. Software does not necessarily + need to check this on return from the call. The case where this occurs is expected to + be rare, and probably signals a non-transient error. In this case the software can + continue on with the recovery phase of the EEH processing, and will eventually hit the same EEH event on further processing. @@ -277,7 +294,7 @@ xml:lang="en"> The device driver initializes the IOA for operations. - +
diff --git a/LoPAR/app_fault_v_errorlog.xml b/LoPAR/app_fault_v_errorlog.xml index 29a30d1..1c23953 100644 --- a/LoPAR/app_fault_v_errorlog.xml +++ b/LoPAR/app_fault_v_errorlog.xml @@ -1,6 +1,6 @@ + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en" + xml:id="dbdoclet.50569385_36278"> When to use: Fault vs. Error Log Indicators (Lightpath Mode) This appendix gives @@ -113,7 +116,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo - + All diff --git a/LoPAR/app_firmware_dump.xml b/LoPAR/app_firmware_dump.xml index abf2ce8..f338ae1 100644 --- a/LoPAR/app_firmware_dump.xml +++ b/LoPAR/app_firmware_dump.xml @@ -1,6 +1,6 @@ + xmlns:xi="http://www.w3.org/2001/XInclude" + xmlns:xlink="http://www.w3.org/1999/xlink" + version="5.0" + xml:id="dbdoclet.50569388_37308"> Glossary This glossary contains an alphabetical list of terms, phrases, and abbreviations used in this document. diff --git a/LoPAR/app_pa_processor_binding.xml b/LoPAR/app_pa_processor_binding.xml index 82ad959..314e6fc 100644 --- a/LoPAR/app_pa_processor_binding.xml +++ b/LoPAR/app_pa_processor_binding.xml @@ -1,6 +1,6 @@ + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en" + xml:id="dbdoclet.50569383_58396"> Platform Dependent hcall()s This appendix defines the set of hypervisor calls (hcall()s) that are diff --git a/LoPAR/app_splar.xml b/LoPAR/app_splar.xml index 510b809..5a9907d 100644 --- a/LoPAR/app_splar.xml +++ b/LoPAR/app_splar.xml @@ -1,8 +1,28 @@ + + + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en" + xml:id="dbdoclet.50569367_15730"> SPLPAR Characteristics Definitions
- SPLPAR Characteristics Definitions + SPLPAR Characteristics Definitions This appendix defines the string that is returned by the ibm,get-system-parameter RTAS call when the parameter token value of 20 diff --git a/LoPAR/app_virtual_nic.xml b/LoPAR/app_virtual_nic.xml index a0a95fa..57e5873 100644 --- a/LoPAR/app_virtual_nic.xml +++ b/LoPAR/app_virtual_nic.xml @@ -1,6 +1,26 @@ + + - A Protocol for VNIC Communications + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en" + xml:id="dbdoclet.50569384_75285"> + A Protocol for VNIC Communications
Introduction diff --git a/LoPAR/app_virtual_scsi.xml b/LoPAR/app_virtual_scsi.xml index 41d8fac..8e59367 100644 --- a/LoPAR/app_virtual_scsi.xml +++ b/LoPAR/app_virtual_scsi.xml @@ -1,5 +1,25 @@ + + + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en" + xml:id="dbdoclet.50569379_75285"> A Protocol for VSCSI Communications
diff --git a/LoPAR/app_virtual_tpm.xml b/LoPAR/app_virtual_tpm.xml index 821d922..73993b5 100644 --- a/LoPAR/app_virtual_tpm.xml +++ b/LoPAR/app_virtual_tpm.xml @@ -1,6 +1,6 @@ + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en" + xml:id="ch_virtual_trusted_platform_module"> Virtual Trusted Platform Module (VTPM)
diff --git a/LoPAR/app_virtual_tty.xml b/LoPAR/app_virtual_tty.xml index f47a7c1..07666c4 100644 --- a/LoPAR/app_virtual_tty.xml +++ b/LoPAR/app_virtual_tty.xml @@ -1,5 +1,25 @@ + + + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en" + xml:id="dbdoclet.50569375_64200"> A Protocol for a Virtual TTY Interface
@@ -78,7 +98,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo - + 0x0 @@ -166,7 +186,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo - + 0x0 @@ -266,7 +286,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo - + 0x6 @@ -421,7 +441,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo - + 0x6 @@ -472,7 +492,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo - + TSCD @@ -553,7 +573,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo - + 0x0 @@ -664,7 +684,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo - + 0x0 @@ -833,7 +853,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo - + 0xFF diff --git a/LoPAR/app_vmc_comm.xml b/LoPAR/app_vmc_comm.xml index 3fd8aa0..9b8155d 100644 --- a/LoPAR/app_vmc_comm.xml +++ b/LoPAR/app_vmc_comm.xml @@ -1,5 +1,24 @@ + + + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en"> A Protocol for VMC Communications
@@ -72,7 +91,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -123,7 +142,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -240,7 +259,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -402,7 +421,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -492,7 +511,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -570,7 +589,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -646,7 +665,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -723,7 +742,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -834,7 +853,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -914,7 +933,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -1022,7 +1041,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B @@ -1102,7 +1121,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + 1 B diff --git a/LoPAR/bk_main.xml b/LoPAR/bk_main.xml index e8791f7..ca0ff73 100644 --- a/LoPAR/bk_main.xml +++ b/LoPAR/bk_main.xml @@ -1,6 +1,6 @@ - + + About This Document diff --git a/LoPAR/ch_address_map.xml b/LoPAR/ch_address_map.xml index 1c3ee5f..61b85e1 100644 --- a/LoPAR/ch_address_map.xml +++ b/LoPAR/ch_address_map.xml @@ -1,6 +1,25 @@ - + + + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en" + xml:id="dbdoclet.50569328_Address-Map"> Address Map The address map of an LoPAR platform is made up of several distinct diff --git a/LoPAR/ch_dynamic_reconfig.xml b/LoPAR/ch_dynamic_reconfig.xml index 6c67c91..3b786de 100644 --- a/LoPAR/ch_dynamic_reconfig.xml +++ b/LoPAR/ch_dynamic_reconfig.xml @@ -1,3 +1,20 @@ + + - + + + Interrupt Controller This chapter specifies the requirements for the LoPAR interrupt @@ -306,7 +322,7 @@ xml:lang="en"> particular, these calls assign additional MSI resources to an IOA function (as defined by its PCI configuration address: PHB_Unit_ID_Hi, PHB_Unit_ID_Low, and config_addr), when supported by the platform. - See for more information on theses RTAS calls for + See for more information on theses RTAS calls for MSI management. This architecture will refer generically to the MSI and MSI-X capabilities as simply “MSI,” except where differentiation is diff --git a/LoPAR/ch_introduction.xml b/LoPAR/ch_introduction.xml index 2512dc4..d399ae3 100644 --- a/LoPAR/ch_introduction.xml +++ b/LoPAR/ch_introduction.xml @@ -1,130 +1,146 @@ - - + + + Introduction - - This architecture specification provides a comprehensive computer - system platform-to-software interface definition, combined with minimum system - requirements, that enables the development of and software porting to a range - of compatible industry-standard computer systems from workstations through - servers. These systems are based on the requirements defined in - The - term “Processor Architecture” (PA) is used throughout this - document to mean compliance with the requirements specified in - .. The definition supports - the development of both uniprocessor and multiprocessor system + + This architecture specification provides a comprehensive computer + system platform-to-software interface definition, combined with minimum system + requirements, that enables the development of and software porting to a range + of compatible industry-standard computer systems from workstations through + servers. These systems are based on the requirements defined in + The + term “Processor Architecture” (PA) is used throughout this + document to mean compliance with the requirements specified in + .. The definition supports + the development of both uniprocessor and multiprocessor system implementations. - A key attribute and benefit of this architecture is the ability of - platform developers to have degrees of freedom of implementation below the - level of architected interfaces and therefore have the opportunity for adding - unique value. This flexibility is achieved through architecture facilities - including: (1) device drivers; (2) Open Firmware (OF); (3) - Run-Time Abstraction Services (RTAS); - and (4) hardware abstraction layers. The role of items 1 - and 4 are described in separate operating system (OS) documentation. The role - that items 2 and 3 play in this architecture will be described in subsequent + A key attribute and benefit of this architecture is the ability of + platform developers to have degrees of freedom of implementation below the + level of architected interfaces and therefore have the opportunity for adding + unique value. This flexibility is achieved through architecture facilities + including: (1) device drivers; (2) Open Firmware (OF); (3) + Run-Time Abstraction Services (RTAS); + and (4) hardware abstraction layers. The role of items 1 + and 4 are described in separate operating system (OS) documentation. The role + that items 2 and 3 play in this architecture will be described in subsequent paragraphs and chapters. - This architecture combines leading-edge technologies to create a - superior computing platform. By design, it supports a wide range of computing - needs including personal productivity, engineering design, data management, - information analysis, education, desktop publishing, multimedia, entertainment, - and database, file, and application servers. This architecture effectively - leverages industry-standard I/O through the PCI bus. Systems based on this - architecture are expected to offer price/performance advantages and to address + This architecture combines leading-edge technologies to create a + superior computing platform. By design, it supports a wide range of computing + needs including personal productivity, engineering design, data management, + information analysis, education, desktop publishing, multimedia, entertainment, + and database, file, and application servers. This architecture effectively + leverages industry-standard I/O through the PCI bus. Systems based on this + architecture are expected to offer price/performance advantages and to address the expected growth in computing performance and functionality. - Architecture Note: In modern platforms, designers may choose - between various PCI topology standards. This architecture uses the term - “PCI” as a general term to describe the most recent versions of - all forms of PCI standards including any approved Engineering Change Requests - (ECRs) against them. In cases where there are significant differences between - individual PCI standards, the following terminology is used to differentiate + Architecture Note: In modern platforms, designers may choose + between various PCI topology standards. This architecture uses the term + “PCI” as a general term to describe the most recent versions of + all forms of PCI standards including any approved Engineering Change Requests + (ECRs) against them. In cases where there are significant differences between + individual PCI standards, the following terminology is used to differentiate between the PCI standards. - + - The term “conventional PCI” refers to behavior or - features that conform to the most recent version of the - , including any approved ECRs against it. + The term “conventional PCI” refers to behavior or + features that conform to the most recent version of the + , including any approved ECRs against it. - + - The term “PCI-X” refers to behavior or features that - conform to the most recent version of the + The term “PCI-X” refers to behavior or features that + conform to the most recent version of the , including any approved ECRs against it. - + - The term “PCI Express” refers to behavior or features - that conform to the most recent version of the - including any approved ECRs against it. In - addition, the terms “bus,” “bridge” and “PCI - Host Bridge (PHB)” used in relation to “PCI” throughout - this architecture may refer to a PCI Express “link,” + The term “PCI Express” refers to behavior or features + that conform to the most recent version of the + including any approved ECRs against it. In + addition, the terms “bus,” “bridge” and “PCI + Host Bridge (PHB)” used in relation to “PCI” throughout + this architecture may refer to a PCI Express “link,” “switch,” and “root complex” respectively. - - + +
Platform Topology - To the experienced computer designer and system manufacturer, much of - the content of this architecture will be familiar. A typical desktop topology - is shown in . This topology consists - of a single PA processor, volatile System Memory, and a single Host Bridge - providing a PCI Bus. The PCI Bus provides for connection of I/O adapters - (IOAs). See for the definition of an + To the experienced computer designer and system manufacturer, much of + the content of this architecture will be familiar. A typical desktop topology + is shown in . This topology consists + of a single PA processor, volatile System Memory, and a single Host Bridge + providing a PCI Bus. The PCI Bus provides for connection of I/O adapters + (IOAs). See for the definition of an IOA. - A more complex general topology is shown in - . All platforms consist of one or more PA - processors, a volatile System Memory separate from other subsystems, and a - number of IOAs, which may initiate transactions to System Memory. The - processors are linked over the primary processor bus/switch to each other, to - the System Memory, and to one or more Host Bridges. In general, IOAs do not - connect to the primary processor bus/switch. The Host Bridges connect to - secondary buses which have IOAs connected to them. In turn, one or more bus - bridges may be employed to tertiary buses (and beyond) with additional IOAs - connected to them. Typically, the bus speeds and throughput decrease and the - number of supportable loads increases as one progresses from the primary + A more complex general topology is shown in + . All platforms consist of one or more PA + processors, a volatile System Memory separate from other subsystems, and a + number of IOAs, which may initiate transactions to System Memory. The + processors are linked over the primary processor bus/switch to each other, to + the System Memory, and to one or more Host Bridges. In general, IOAs do not + connect to the primary processor bus/switch. The Host Bridges connect to + secondary buses which have IOAs connected to them. In turn, one or more bus + bridges may be employed to tertiary buses (and beyond) with additional IOAs + connected to them. Typically, the bus speeds and throughput decrease and the + number of supportable loads increases as one progresses from the primary processor bus to more remote buses. - There are variations on these topologies, which are likely to occur - and are therefore worth describing below. This architecture describes - interfaces, not implementation. The logical software model must remain the + There are variations on these topologies, which are likely to occur + and are therefore worth describing below. This architecture describes + interfaces, not implementation. The logical software model must remain the same, even if the physical topology is different. - + - In a smaller platform, the Host Bridge and/or the memory and/or an - IOA may be integrated into a single chip. In this case, the topology would not - look like from a chip point of view, + In a smaller platform, the Host Bridge and/or the memory and/or an + IOA may be integrated into a single chip. In this case, the topology would not + look like from a chip point of view, but instead would be integrated onto the single chip. - + - In a larger platform, secondary buses may be implemented, with two - or more Host Bridges, as two or more parallel expansion buses for performance - reasons. Similarly, tertiary buses may be two or more parallel expansion buses - off each secondary bus. This is indicated by the ellipses near the Host Bridge + In a larger platform, secondary buses may be implemented, with two + or more Host Bridges, as two or more parallel expansion buses for performance + reasons. Similarly, tertiary buses may be two or more parallel expansion buses + off each secondary bus. This is indicated by the ellipses near the Host Bridge and the Bus Bridge. - + - In a high performance platform, with multiple processors and - multiple memoriea switch may be employed to allow multiple parallel accesses - by the processors to memory. The path through the switches would be decided by - the addressing of ths, a switch may be employed to allow multiple parallel accesses - by the processors to memory. The path through the switches would be decided by + In a high performance platform, with multiple processors and + multiple memoriea switch may be employed to allow multiple parallel accesses + by the processors to memory. The path through the switches would be decided by + the addressing of ths, a switch may be employed to allow multiple parallel accesses + by the processors to memory. The path through the switches would be decided by the addressing of the memory. - - Each of the following chapters provides information necessary to - successfully implement compliant systems. It is recommended that the reader - become thoroughly familiar with the contents of these chapters and their - references prior to beginning system or software development. It is anticipated - that standard chip sets will simplify the development of compliant - implementations consistent with the topologies shown below and will be + + Each of the following chapters provides information necessary to + successfully implement compliant systems. It is recommended that the reader + become thoroughly familiar with the contents of these chapters and their + references prior to beginning system or software development. It is anticipated + that standard chip sets will simplify the development of compliant + implementations consistent with the topologies shown below and will be available from third-party industry sources.
Typical Desktop Topology @@ -140,9 +156,9 @@ xml:lang="en">
- Note: To enable the implementation of a large number of I/O adapters in a large - system, the Host Bridge may be split into two pieces -- a Hub and a Bridge -- - with the two connected by a cable, thus enabling the I/O adapters to be housed + Note: To enable the implementation of a large number of I/O adapters in a large + system, the Host Bridge may be split into two pieces -- a Hub and a Bridge -- + with the two connected by a cable, thus enabling the I/O adapters to be housed at a distance from the main processor enclosure.
diff --git a/LoPAR/ch_io_devices.xml b/LoPAR/ch_io_devices.xml index 8e508ce..1294575 100644 --- a/LoPAR/ch_io_devices.xml +++ b/LoPAR/ch_io_devices.xml @@ -1,6 +1,24 @@ - + + + xmlns:xl="http://www.w3.org/1999/xlink" + version="5.0" + xml:lang="en"> I/O Devices This chapter describes requirements for IOAs. It adds detail to areas @@ -299,7 +317,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + Command @@ -583,7 +601,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en"> - + Entire adapter assigned to OS, IOV not enabled diff --git a/LoPAR/ch_io_topology.xml b/LoPAR/ch_io_topology.xml index babfb62..0dc3d21 100644 --- a/LoPAR/ch_io_topology.xml +++ b/LoPAR/ch_io_topology.xml @@ -1,9 +1,25 @@ - - + + + I/O Bridges and Topologies There will be at least one bridge in a platform which interfaces to the diff --git a/LoPAR/ch_lpar_option.xml b/LoPAR/ch_lpar_option.xml index aa40499..59324bd 100644 --- a/LoPAR/ch_lpar_option.xml +++ b/LoPAR/ch_lpar_option.xml @@ -1,5 +1,25 @@ - + + + Logical Partitioning Option
@@ -8077,7 +8097,7 @@ hcall ( const int64 H_BLOCK_REMOVE, /* Function Code */ 7 - + Control @@ -8117,7 +8137,7 @@ hcall ( const int64 H_BLOCK_REMOVE, /* Function Code */ - + Type   @@ -23176,7 +23196,7 @@ hcall ( const H_STOP_COP_OP, - + 43:44 @@ -23410,7 +23430,7 @@ hcall ( const uint64 H_MEMSTAT_CTRL, uint64 flags);]]> 31 - + 0 R @@ -23477,7 +23497,7 @@ hcall ( const uint64 H_MEMSTAT_CTRL, uint64 flags);]]> - + 0 @@ -23569,7 +23589,7 @@ hcall ( const uint64 H_MEMSTAT_CTRL, uint64 flags);]]> - + 0 @@ -23644,7 +23664,7 @@ hcall ( const uint64 H_MEMSTAT_CTRL, uint64 flags);]]> - + 0 @@ -23954,7 +23974,7 @@ hcall ( const uint64 H_RETURN_PAGEINFO, 7 - + 0 Ar @@ -24140,7 +24160,7 @@ hcall ( const uint64 H_RETURN_PAGEINFO, - + lpx diff --git a/LoPAR/ch_nonvolatile_memory.xml b/LoPAR/ch_nonvolatile_memory.xml index 00afa53..862b42c 100644 --- a/LoPAR/ch_nonvolatile_memory.xml +++ b/LoPAR/ch_nonvolatile_memory.xml @@ -1,8 +1,24 @@ - - + + + Non-Volatile Memory This chapter describes the requirements relating to Non-Volatile diff --git a/LoPAR/ch_notifications.xml b/LoPAR/ch_notifications.xml index 7774d9d..3e1f53a 100644 --- a/LoPAR/ch_notifications.xml +++ b/LoPAR/ch_notifications.xml @@ -1,6 +1,6 @@ + Non Uniform Memory Access (NUMA) Option
diff --git a/LoPAR/ch_processors_memory.xml b/LoPAR/ch_processors_memory.xml index 4e1b7a3..1141f30 100644 --- a/LoPAR/ch_processors_memory.xml +++ b/LoPAR/ch_processors_memory.xml @@ -1,6 +1,24 @@ - - + + + Processor and Memory The purpose of this chapter is to specify the processor and memory diff --git a/LoPAR/ch_product_topology.xml b/LoPAR/ch_product_topology.xml index eade577..310bb17 100644 --- a/LoPAR/ch_product_topology.xml +++ b/LoPAR/ch_product_topology.xml @@ -1,9 +1,25 @@ - - + + + Product Topology
diff --git a/LoPAR/ch_rtas.xml b/LoPAR/ch_rtas.xml index 9f26646..26457cc 100644 --- a/LoPAR/ch_rtas.xml +++ b/LoPAR/ch_rtas.xml @@ -1,6 +1,6 @@ + The Symmetric Multiprocessor Option This architecture supports the implementation of symmetric diff --git a/LoPAR/ch_system_reqs.xml b/LoPAR/ch_system_reqs.xml index a2a18e6..e166f2d 100644 --- a/LoPAR/ch_system_reqs.xml +++ b/LoPAR/ch_system_reqs.xml @@ -1,9 +1,25 @@ - - + + + System Requirements This chapter gives an operational overview of LoPAR systems and diff --git a/LoPAR/ch_virtual_io.xml b/LoPAR/ch_virtual_io.xml index 8f1bc55..d829b38 100644 --- a/LoPAR/ch_virtual_io.xml +++ b/LoPAR/ch_virtual_io.xml @@ -1,5 +1,25 @@ - + + + Virtualized Input/Output Virtualized I/O is an optional feature of platforms that have hypervisor support. Virtual I/O (VIO) provides to a given partition the diff --git a/LoPAR/pom.xml b/LoPAR/pom.xml index aef46c3..73c3c0b 100644 --- a/LoPAR/pom.xml +++ b/LoPAR/pom.xml @@ -1,7 +1,23 @@ - + + org.openpowerfoundation.docs diff --git a/LoPAR/sec_LoPAPR_audience.xml b/LoPAR/sec_LoPAPR_audience.xml index c6a5a1b..58b7591 100644 --- a/LoPAR/sec_LoPAPR_audience.xml +++ b/LoPAR/sec_LoPAPR_audience.xml @@ -1,7 +1,7 @@ -
- - + + Audience for This Document - - This document defines the platform and system requirements for designing - LoPAR platforms. This document is the primary source of information that a platform, - OS, or hardware component developer would need to create compatible products. - Additional requirements are defined by the industry standards referenced in this + + This document defines the platform and system requirements for designing + LoPAR platforms. This document is the primary source of information that a platform, + OS, or hardware component developer would need to create compatible products. + Additional requirements are defined by the industry standards referenced in this document. - - This document describes the platform to OS interface which must be provided - in these platforms. Platform designers must assemble components and firmware which - match this interface. Also, the document defines minimum system configuration - requirements. Platform designers must meet or exceed these minimums to build a + + This document describes the platform to OS interface which must be provided + in these platforms. Platform designers must assemble components and firmware which + match this interface. Also, the document defines minimum system configuration + requirements. Platform designers must meet or exceed these minimums to build a standard platform. - - This document must be used by those designing compatible software including - the OS, boot software, or firmware. If a function is supported, software developers - must provide support for the interfaces described in this document. This software - must provide the mandatory functions and capabilities as described in the requirements - in this document. However, this document does not limit this software from going beyond - the specification through software tailored to specific hardware. For example, the OS - must implement the interface to the required abstracted interfaces to hardware, but the + + This document must be used by those designing compatible software including + the OS, boot software, or firmware. If a function is supported, software developers + must provide support for the interfaces described in this document. This software + must provide the mandatory functions and capabilities as described in the requirements + in this document. However, this document does not limit this software from going beyond + the specification through software tailored to specific hardware. For example, the OS + must implement the interface to the required abstracted interfaces to hardware, but the OS may also implement fast paths to specific hardware that it recognizes. - +
diff --git a/LoPAR/sec_LoPAPR_conventions.xml b/LoPAR/sec_LoPAPR_conventions.xml index b793238..da39993 100644 --- a/LoPAR/sec_LoPAPR_conventions.xml +++ b/LoPAR/sec_LoPAPR_conventions.xml @@ -1,7 +1,7 @@ -
- - +
+ + + Document-specific Conventions - + Requirement Enumeration - Within the body of this document requirements are clearly defined by separate - paragraphs beginning with a bold text sequence number. A list of all these are - available as a separate document. These requirements may point to other standards - documents, or figures or tables which conveniently show the requirement. The - referenced material becomes part of the requirements in this document. Users of this - document must comply with these requirements to build a standard platform. Other - material in this document is supportive description of these requirements, architecture - notes, or implementation notes. Architecture or implementation notes are flagged with - a descriptive phrase—for example, “Hardware Implementation Note”— - and followed by indented paragraphs. The descriptive material and notes provide no + Within the body of this document requirements are clearly defined by separate + paragraphs beginning with a bold text sequence number. A list of all these are + available as a separate document. These requirements may point to other standards + documents, or figures or tables which conveniently show the requirement. The + referenced material becomes part of the requirements in this document. Users of this + document must comply with these requirements to build a standard platform. Other + material in this document is supportive description of these requirements, architecture + notes, or implementation notes. Architecture or implementation notes are flagged with + a descriptive phrase—for example, “Hardware Implementation Note”— + and followed by indented paragraphs. The descriptive material and notes provide no additional requirements and may be used for their information content. - + Big-Endian Numbering - Big-Endian numbering of bytes and bits is used in this document, unless - indicated otherwise. Numbering of bits starts at 0 for the most significant bit and - continues to the least significant bit, unless indicated otherwise. All data structures - used for communicating between the OS and the platform (for example, RTAS and hypervisor + Big-Endian numbering of bytes and bits is used in this document, unless + indicated otherwise. Numbering of bits starts at 0 for the most significant bit and + continues to the least significant bit, unless indicated otherwise. All data structures + used for communicating between the OS and the platform (for example, RTAS and hypervisor calls) will be in Big-Endian format, unless otherwise designated. - + Hypertext Links - This document makes use of hypertext links. Cross references, Table of Contents - entries, List of Tables entries, and List of Figures entries are all clickable hypertext + This document makes use of hypertext links. Cross references, Table of Contents + entries, List of Tables entries, and List of Figures entries are all clickable hypertext links, to make navigation of the document easier. - + Specific Terms In this document: - The term “Processor Architecture” (PA) is used to mean compliance with + The term “Processor Architecture” (PA) is used to mean compliance with the requirements specified in . The term “processor” is used as a general term to mean “processor, - ” or “processor core,” or “thread of a multi-threaded processor - design.” In any case where it makes a difference, the specific terminology for that + ” or “processor core,” or “thread of a multi-threaded processor + design.” In any case where it makes a difference, the specific terminology for that case is used. - The term “real” used in relationship with addresses is a generic term - that means “processor real address” when the platform is running in SMP (non-LPAR) - mode and partition “logical real address” when the platform is running in LPAR + The term “real” used in relationship with addresses is a generic term + that means “processor real address” when the platform is running in SMP (non-LPAR) + mode and partition “logical real address” when the platform is running in LPAR mode. - The term “PCI” is used as a general term to describe the most recent - versions of all forms of PCI standards. In cases where there are significant differences - between individual PCI standards, the following terminology is used to differentiate between + The term “PCI” is used as a general term to describe the most recent + versions of all forms of PCI standards. In cases where there are significant differences + between individual PCI standards, the following terminology is used to differentiate between the PCI standards: conventional PCI, PCI-X, and PCI Express. - + Typographical Conventions - Typographical conventions used in this document are described in + Typographical conventions used in this document are described in .   @@ -98,14 +101,14 @@ Rn-m-x. - A requirement number. The number “n” indicates a requirement - sequence number and is changed only when it is necessary change the sequence numbers - of one or more requirements on an update. The number “m” is the section - that the requirement appears in, and the number “x” is the number of the - requirement within that section. The sequence numbers are automatically generated and - are restarted at the beginning of each new section. Sequence numbers for existing - requirements will not change unless it becomes necessary to insert a requirement between - other requirements or to add a section that renumbers other sections (at which point, + A requirement number. The number “n” indicates a requirement + sequence number and is changed only when it is necessary change the sequence numbers + of one or more requirements on an update. The number “m” is the section + that the requirement appears in, and the number “x” is the number of the + requirement within that section. The sequence numbers are automatically generated and + are restarted at the beginning of each new section. Sequence numbers for existing + requirements will not change unless it becomes necessary to insert a requirement between + other requirements or to add a section that renumbers other sections (at which point, the number “n” will be incremented for the next publication of the document). @@ -116,8 +119,8 @@ Courier Bold - Indicates OF properties, methods, configuration variables, node names - and encode functions (for example, encode-int and + Indicates OF properties, methods, configuration variables, node names + and encode functions (for example, encode-int and encode-string ). In addition, OF properties are enclosed in quotes. Indicates NVRAM partition names @@ -139,44 +142,44 @@ 0xF... FFF100 - This hexadecimal notation represents a replication of the hexadecimal - character to the right of the ellipsis to fill out the field width. For example, the - address 0xF... FFF100 would be 0xFFFFF100 on a processor with a 32-bit address bus or + This hexadecimal notation represents a replication of the hexadecimal + character to the right of the ellipsis to fill out the field width. For example, the + address 0xF... FFF100 would be 0xFFFFF100 on a processor with a 32-bit address bus or 0xFFFFFFFFFFFFF100 on a processor with a 64-bit address bus. 0:9 - Ranges of bits are specified by two numbers separated by a colon. The + Ranges of bits are specified by two numbers separated by a colon. The range includes the first number, all numbers in between, and the last number. 0xm-0xn - A range of addresses or values within the document is always inclusive, + A range of addresses or values within the document is always inclusive, from m up to and including n. <token> - This notation means the character or character string named within the - less than and greater than symbols is used in the place of the symbols and name. For + This notation means the character or character string named within the + less than and greater than symbols is used in the place of the symbols and name. For instance, the property name “ibm,sensor- <token> - ” indicates the set of properties + ” indicates the set of properties “ibm,sensor-9000”, “ibm,sensor-9001” , . . . Reserved For Compatibility - This notation is a placeholder used to reserve numbering (for example, - chapter, section and requirement numbers) so that subsequent numbering remains consistent + This notation is a placeholder used to reserve numbering (for example, + chapter, section and requirement numbers) so that subsequent numbering remains consistent with document changes. NULL vs. null - NULL designates an ASCII NULL string (0x00). The term “null” + NULL designates an ASCII NULL string (0x00). The term “null” indicates the empty set.
- +
diff --git a/LoPAR/sec_LoPAPR_goals.xml b/LoPAR/sec_LoPAPR_goals.xml index 372705a..57a9426 100644 --- a/LoPAR/sec_LoPAPR_goals.xml +++ b/LoPAR/sec_LoPAPR_goals.xml @@ -1,7 +1,7 @@ -
- - +
+ + + Goals of This Specification - + The specific goals of this specification are as follows: - + - + - To create a stable platform architecture to be used by platforms based on processors - defined by . Processor - implementations based on this + To create a stable platform architecture to be used by platforms based on processors + defined by . Processor + implementations based on this architecture include IBM POWER8™ processors and their successors. - + - To create an architecture which will allow platforms to operate with previous versions + To create an architecture which will allow platforms to operate with previous versions of the OS (“n-1” capability). To leverage existing and future industry-standard buses and interfaces. - + - To provide a flexible address map. Another key attribute of this specification - is the relocatability of devices and subsystems within the Processor Architecture (PA) - address space. Subsystem address information, which defines where I/O Adapters (IOAs) - reside, is detected by the OF and passed to the OS in the device tree. This architecture - accommodates the use of multiple identical buses and IOAs in the same platform without + To provide a flexible address map. Another key attribute of this specification + is the relocatability of devices and subsystems within the Processor Architecture (PA) + address space. Subsystem address information, which defines where I/O Adapters (IOAs) + reside, is detected by the OF and passed to the OS in the device tree. This architecture + accommodates the use of multiple identical buses and IOAs in the same platform without address conflicts. - To build upon the OF boot environment defined in + To build upon the OF boot environment defined in . - + To provide an architecture which can evolve as technology changes. - + - To minimize the support cost for multiple OS versions through the definition of common - platform abstraction techniques. Common and compatible approaches to the abstraction of + To minimize the support cost for multiple OS versions through the definition of common + platform abstraction techniques. Common and compatible approaches to the abstraction of hardware will reduce the burden on hardware developers who produce differentiated machines. - To architect a mechanism for error handling, error reporting, and fault isolation. This - architecture provides for the implementation of more robust systems, if desired by the system + To architect a mechanism for error handling, error reporting, and fault isolation. This + architecture provides for the implementation of more robust systems, if desired by the system developers. - + To architect a mechanism for Dynamic Reconfiguration of the hardware. - + - To provide an architecture which allows for the logical partitioning of system resources, + To provide an architecture which allows for the logical partitioning of system resources, in order to execute multiple concurrent OS instances. - - + +
diff --git a/LoPAR/sec_LoPAPR_reading.xml b/LoPAR/sec_LoPAPR_reading.xml index b225386..d101772 100644 --- a/LoPAR/sec_LoPAPR_reading.xml +++ b/LoPAR/sec_LoPAPR_reading.xml @@ -1,7 +1,7 @@ -
- - +
+ + + Suggested Reading - - provides a full list of references and ordering information + + provides a full list of references and ordering information for these references. - This document assumes the reader has an understanding of computer architecture in general, - the Processor Architecture, the various Peripheral Component Interconnect (PCI) specifications, - and OF. Some understanding of the current personal computer and workstation architectures is also + This document assumes the reader has an understanding of computer architecture in general, + the Processor Architecture, the various Peripheral Component Interconnect (PCI) specifications, + and OF. Some understanding of the current personal computer and workstation architectures is also useful. A list of suggested background reading includes: - + - . - Note that this specification is referred to as the “Processor Architecture,” or “PA,” + . + Note that this specification is referred to as the “Processor Architecture,” or “PA,” in the body of this document. @@ -48,5 +52,5 @@ and relevant bindings - +
diff --git a/LoPAR/sec_error_codes.xml b/LoPAR/sec_error_codes.xml index 9975d8a..6b91ade 100644 --- a/LoPAR/sec_error_codes.xml +++ b/LoPAR/sec_error_codes.xml @@ -1,6 +1,6 @@ -
- + Environmental and Power Warnings - + Environmental and Power Warnings (EPOW) is an option that provides a means for the platform to inform the OS of these types of events. The intent is to enable the OS to provide basic information to the user about @@ -32,86 +32,86 @@ the loss of power. Even on platforms that provide hardware protection of data during environmental events, EPOW notification allows discrimination between I/O errors caused by hardware failures versus EPOW events. - + These warnings include action codes that the platform can use to influence the OS behavior when various hardware components fail. For example, a fan failure where the system can continue to operate in the safe cooling range may just generate an action code of WARN_COOLING, but a fan failure where the system cannot operate in the safe cooling range may generate an action code of SYSTEM_HALT. - + Implementation Note: Hardware cannot assume that the OS will process or take action on these warnings. These warnings are only provided to the OS in order to allow the OS a chance to cleanly abort operations in progress at the time of the warning. Hardware still assumes responsibility for preventing hardware damage due to environmental or power problems. - - An OS that wants to be EPOW-aware will look for the + + An OS that wants to be EPOW-aware will look for the epow-events node in the OF device tree, enable the - interrupts listed in its + interrupts listed in its “interrupts” property, and provide an - interrupt handler to call + interrupt handler to call check-exception when one of those interrupts are received. - - When an EPOW event occurs, whether reported by - check-exception or + + When an EPOW event occurs, whether reported by + check-exception or event-scan, RTAS will directly pass back the EPOW - sensor value as part of the Extended Error Log format as described in + sensor value as part of the Extended Error Log format as described in , assuming the extended log is requested. Doing so avoids the need for the OS to make an extra RTAS call - to obtain the sensor value. For critical power problems, the + to obtain the sensor value. For critical power problems, the check-exception function is used to immediately - report changes of state to the OS, while the + report changes of state to the OS, while the get-sensor-state function allows the OS to monitor the condition (for example, loss of AC power) to see if the problem corrects itself. - + - + - R1-R1--1. If the platform supports Environmental and Power Warnings by including a EPOW device tree entry, then the platform - must support the EPOW sensor for the + must support the EPOW sensor for the get-sensor-state RTAS function. - + - R1-R1--2. The EPOW sensor, if provided, must contain - the EPOW action code (defined in + the EPOW action code (defined in ) in the least significant 4 bits. In cases where multiple EPOW actions are required, the action code with the highest numerical value (where 0 is lowest and 7 is highest) must be presented to the OS. The platform may implement any subset of - these action codes, but must operate as described in + these action codes, but must operate as described in for those it does implement. - + - R1-R1--3. To ensure adequate response time, platforms which implement the EPOW_MAIN_ENCLOSURE or EPOW_POWER_OFF - action codes must do so via interrupt and - check-exception notification, rather than by - event-scan notification. - (Except as modified by Requirement + action codes must do so via interrupt and + check-exception notification, rather than by + event-scan notification. + (Except as modified by Requirement ) - + - R1-R1--4. If the platform @@ -120,54 +120,54 @@ to the EPOW event. - + - R1-R1--5. For interrupt-driven EPOW events, the platform must ensure that an EPOW interrupt is not lost in the case where - a numerically higher-priority EPOW event occurs between the time when + a numerically higher-priority EPOW event occurs between the time when check-exception gathers the sensor value and when it resets the interrupt. - + - R1-R1--6. For SYSTEM_SHUTDOWN EPOW class 3, after a SYSTEM_SHUTDOWN EPOW commences and when the delay interval timer expires, - if an + if an “ibm,recoverable-epow3” encode-null - property in the + property in the /rtas node is present, then the OS code that manages - preserving storage must check the EPOW sensor state and the + preserving storage must check the EPOW sensor state and the “ibm,request-partition-shutdown” property if present. A normal boot must only occur when the EPOW sensor state indicates that the EPOW condition requiring a shutdown no longer exists - (EPOW 0) and the - “ibm,request-partition-shutdown” + (EPOW 0) and the + “ibm,request-partition-shutdown” is not present. Otherwise, the code that manages preserving storage must take the action as identified by the property. - + - + Implementation Note: One way for hardware to prevent the loss of an EPOW interrupt is by deferring the generation of a new EPOW interrupt - until the existing EPOW interrupt is reset by a call to the RTAS + until the existing EPOW interrupt is reset by a call to the RTAS check-exception function. Another way is to ignore resets to the interrupt until all EPOW events have been reported. - + EPOW Action Codes - - + + @@ -181,14 +181,14 @@ Value - + Description - + EPOW_RESET/MESSAGE @@ -289,32 +289,32 @@
- + Software Implementation Note: A recommended OS processing method for an EPOW_MAIN_ENCLOSURE event is as follows: - + - + Prepare for shutdown, mask the EPOW interrupt, and wait for 50 milliseconds. Then call get-sensor-state to read the EPOW sensor. - + If the EPOW action code is unchanged, wait an additional 50 milliseconds. - + If the action code is EPOW_POWER_OFF, attempt to power off. Otherwise, the power condition may have stabilized, so interrupts may be enabled and normal operation resumed. - + Implementation Note: EPOW_RESET (EPOW action code 0) may be used to indicate that a previously reported EPOW condition is no @@ -324,7 +324,7 @@ error log that specified the type of WARN_POWER EPOW generated would be set in the EPOW_RESET error log to indicate the specific EPOW event that was reset. - + Systems that do not support an EPOW interrupt would generally be unable to support the EPOW action codes 5 and 7. In those cases, there could not be an EPOW event to indicate a loss of power. However, after @@ -332,5 +332,5 @@ the system had lost power previously and the power had been restored. The EPOW_RESET should only be used in this way if the system is unable to generate an EPOW class 5 or class 7. - +
diff --git a/LoPAR/sec_rtas_environment.xml b/LoPAR/sec_rtas_environment.xml index 439acf2..7172e43 100644 --- a/LoPAR/sec_rtas_environment.xml +++ b/LoPAR/sec_rtas_environment.xml @@ -1,6 +1,6 @@ -
- + Internal Error Indications - + Hardware may detect a variety of problems during operation, ranging from soft errors which have already been corrected by the time they are reported, to hard errors of such severity that the OS (and perhaps the hardware) cannot meaningfully continue operation. The mechanisms - described in + described in are used to report such errors to the OS. This section describes the architectural sources of errors, and describes a method that platforms can use to report the error. All OSs @@ -36,7 +36,7 @@ may be introduced via RTAS, and the OS may not have to handle the error directly. More robust error detection, reporting, and correcting are at the option of the hardware vendor. - + The @@ -51,12 +51,12 @@ handle such cases, a special hardware mechanism may be provided to gather and store residual error data, to be analyzed when the system goes through a subsequent successful reboot. - + Less critical internal errors may also be signaled to the OS through a platform-specific interrupt in the “Internal - Errors” class, or by periodic polling with the + Errors” class, or by periodic polling with the event-scan RTAS function. - + Architecture Note: The machine check interrupt will not be listed in the OF node for the “Internal Errors” class, since it is a standard architectural mechanism. The machine check interrupt mechanism @@ -69,55 +69,55 @@ connection to the processor machine check interrupt pin, or via a system bus error indicator (for example, Transfer Error Acknowledge - TEA). - + - + - R1-R1--1. OSs must set MSRME=1 prior to the occurrence of a machine check interrupt in order to enable machine check processing via the check-exception RTAS function. - + - Architecture Note: Requirement + Architecture Note: Requirement is not applicable when the FWNMI option is used. - + - + - R1-R1--2. For hardware-detected errors, platforms must generate error indications as - described in + described in , unless the error can be handled through a less severe platform-specific interrupt, or the nature of the error forces a checkstop condition. - + - R1-R1--3. Platforms which detect and report the - errors described in + errors described in must provide information to the OS - via the RTAS + via the RTAS check-exception function, using the reporting format - described in + described in . - + - R1-R1--4. To prevent error @@ -126,7 +126,7 @@ interrupt signaled via the external machine check interrupt pin. - + @@ -135,8 +135,8 @@ - - The intent of Requirement + + The intent of Requirement is to define standard error notification mechanisms for different hardware error types. For most hardware errors, the signaling mechanism is the machine check interrupt, @@ -156,15 +156,15 @@ summarize, platforms should not use platform-specific interrupts to signal hardware errors unless there is a complete hardware/RTAS platform solution for handling such errors. - + - The intent of Requirement + The intent of Requirement is that most hardware errors would be signaled simultaneously to all processors, so that processors could synchronize the error handling process; that is, one processor would be - chosen to do the call to + chosen to do the call to check-exception, while the other processors remained idle so that they would not interfere with RTAS while it gathered machine check error data. While this is a straightforward wiring solution for @@ -178,13 +178,13 @@ such propagation should be avoided, and such errors should be signaled through the machine check interrupt pin to ensure proper error handling. - + - +
Error Indication Mechanisms - + describes the mechanisms by which software will be notified of the occurrence of operational failures @@ -198,12 +198,12 @@ Error Indications for System Operations - - - - - - + + + + + + @@ -238,7 +238,7 @@ - + Processor @@ -451,7 +451,7 @@ Firmware receives a machine check, OS receives - all=1’s data along with a + all=1’s data along with a Status of -1 from the RTAS call @@ -466,7 +466,7 @@ All-1’s data returned, along with a - “Success” + “Success” Status from the RTAS call @@ -482,7 +482,7 @@ Various, except no response from IOA - Firmware receives a machine check, OS receives a + Firmware receives a machine check, OS receives a Status of -1 from the RTAS call @@ -496,7 +496,7 @@ No response from an IOA - Operation ignored, OS receives a “Success” + Operation ignored, OS receives a “Success” Status from the RTAS call @@ -603,21 +603,21 @@ Various, including but not limited to: - - + + Invalid addr accepted by a bridge - + TCE extent - + TCE Page Mapping and Control mis-match or invalid TCE - + @@ -696,7 +696,7 @@
- + Implementation Note: IOAs should, whenever possible, detect the occurrence of PCI errors on DMA and report them via an external interrupt (for possible device driver recovery) or retry the operation. Since @@ -705,7 +705,7 @@ cause a catastrophic error. Systems which wish to recover from these types of errors should choose devices and device drivers which are designed to handle them correctly. - +
diff --git a/LoPAR/sec_rtas_error_reporting.xml b/LoPAR/sec_rtas_error_reporting.xml index d3e7dca..eec581b 100644 --- a/LoPAR/sec_rtas_error_reporting.xml +++ b/LoPAR/sec_rtas_error_reporting.xml @@ -1,6 +1,6 @@
Introduction - + This section describes the data formats used to report events and errors from RTAS to the OS. A common format is used for errors and events to simplify software both in RTAS and in the OS. Both errors and events @@ -36,5 +36,5 @@ mapping exists, and platform features may not be fully supported by the OS. In such cases, error reports may also be non-specific, leaving platform-specific details to platform-aware software. - -
\ No newline at end of file + +
diff --git a/LoPAR/sec_rtas_error_reporting_location_codes.xml b/LoPAR/sec_rtas_error_reporting_location_codes.xml index c0bd3b7..a0f1bdc 100644 --- a/LoPAR/sec_rtas_error_reporting_location_codes.xml +++ b/LoPAR/sec_rtas_error_reporting_location_codes.xml @@ -1,6 +1,6 @@