Replace LoPAR.XXXX ids with proper document references.

Signed-off-by: Jeff Scheel <scheel@us.ibm.com>
pull/2/head
Jeff Scheel 4 years ago
parent 809fc06d01
commit c250b41348

@ -28,38 +28,6 @@
revision, the revision shall apply.</para>
<orderedlist>

<!-- TODO: Uncomment documents needing referencing and comment out local document -->
<listitem>
<para><anchor xml:id="LoPAR.Platform"
xreflabel="Linux on Power Architecture Reference: Platform"/><citetitle>
Linux on Power Architecture Reference: Platform and Device Tree</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="LoPAR.DeviceTree"
xreflabel="Linux on Power Architecture Reference: Device Tree"/><citetitle>
Linux on Power Architecture Reference: Device Tree</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="LoPAR.Error"
xreflabel="Linux on Power Architecture Reference: Error Recovery and Logging"/><citetitle>
Linux on Power Architecture Reference: Error Recovery and Logging</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="LoPAR.Virtualization"
xreflabel="Linux on Power Architecture Reference: Virtualization"/><citetitle>
Linux on Power Architecture Reference: Virtualization</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="LoPAR.RTAS"
xreflabel="Linux on Power Architecture Reference: Runtime Abstraction Services (RTAS)"/><citetitle>
Linux on Power Architecture Reference: Runtime Abstraction Services (RTAS)</citetitle></para>
</listitem>
<!-- End TODO list -->

<listitem>
<para><citetitle>Power ISA</citetitle><anchor xml:id="dbdoclet.50569387_99718"
xreflabel="Power ISA specification"/></para>

@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2016 OpenPOWER Foundation

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
@ -13,13 +13,13 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

-->
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdoclet.50569385_36278">
<title>
When to use: Fault vs. Error Log Indicators (Lightpath Mode)</title>
<para>This appendix gives
<para>This appendix gives
<emphasis>highly</emphasis> recommended Service Indicator activation models
for typical system issues, when the Lightpath mode is implemented. The
purpose of this appendix is to get consistency across platforms, and to
@ -28,18 +28,18 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
that are involved, specifically related to the different types of physical
layouts (for example: deskside, blade and blade chassis, rack-mounted and
particularly high end racks).</para>
<para>This appendix does
<para>This appendix does
<emphasis>not</emphasis> change the architectural requirements specified in
other parts of this document, nor the requirement for implementations to
support those requirements. If there are any inconsistencies between this
appendix and the requirements in the rest of this document, the requirements
take precedence over this appendix. It is very important, therefore, that
designers understand the requirements in this architecture, and more
specifically, those in
specifically, those in
<xref linkend="dbdoclet.50569347_86824" />.</para>
<para><xref linkend="dbdoclet.50569385_72358" /> gives the recommended models. The
general model, though, is still dictated by the following requirement, copied
here from the <xref linkend="LoPAR.Platform" />:</para>
here from the <xref linkend="dbdoclet.50569347_86824" />:</para>
<informalfigure>
<mediaobject>
<imageobject role="html">
@ -54,7 +54,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo

<table frame="all" pgwide="1" xml:id="dbdoclet.50569385_72358">
<title>Service Indicator Activation Models for Typical System
Issues (Lightpath Mode)
Issues (Lightpath Mode)
<emphasis></emphasis></title>
<tgroup cols="7">
<colspec colname="c1" colwidth="15*" />
@ -79,8 +79,8 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<entry nameend="c4" namest="c3">
<para>
<emphasis role="bold">Indicator activation?
<emphasis><?linebreak?>(see notes
<xref linkend="dbdoclet.50569385_14395" xrefstyle="select: nopage" />,
<emphasis><?linebreak?>(see notes
<xref linkend="dbdoclet.50569385_14395" xrefstyle="select: nopage" />,
<xref linkend="dbdoclet.50569385_43948" xrefstyle="select: nopage" />)</emphasis></emphasis>
</para>
</entry>
@ -104,7 +104,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<row>
<entry>
<para>FRU Fault indicator?<?linebreak?>(see notes
<xref linkend="dbdoclet.50569385_57037" xrefstyle="select: nopage" />,
<xref linkend="dbdoclet.50569385_57037" xrefstyle="select: nopage" />,
<xref linkend="dbdoclet.50569385_69283" xrefstyle="select: nopage" />)</para>
</entry>
<entry>
@ -745,7 +745,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<para>no</para>
</entry>
<entry>
<para>See also Requirement
<para>See also Requirement
<xref linkend="dbdoclet.50569347_86824" /></para>
</entry>
</row>
@ -847,13 +847,13 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<para>
<emphasis role="bold">Notes:</emphasis>
</para>
<orderedlist>

<orderedlist>
<listitem xml:id="dbdoclet.50569385_14395">
<para>Never activate both a
Fault indicator and an Error Log indicator for the same problem. See also
Requirement
<xref linkend="dbdoclet.50569347_86824" />, referenced immediately above
Requirement
<xref linkend="dbdoclet.50569347_86824" />, referenced immediately above
<xref linkend="dbdoclet.50569385_72358" />.</para>
</listitem>

@ -867,11 +867,11 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<listitem xml:id="dbdoclet.50569385_57037">
<para>Enclosure Fault
indicators and above are only roll-up indicators and are never activated
without a FRU Fault indicator being activated. Therefore the column in
without a FRU Fault indicator being activated. Therefore the column in
<xref linkend="dbdoclet.50569385_72358" />indicates a FRU Fault indicator.
That is, if no FRU Fault indicator exists for the problem, then the Error Log
indicator is used instead (per Requirement
<xref linkend="dbdoclet.50569347_86824" />, referenced immediately above
indicator is used instead (per Requirement
<xref linkend="dbdoclet.50569347_86824" />, referenced immediately above
<xref linkend="dbdoclet.50569385_72358" />).</para>
</listitem>

@ -880,11 +880,11 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
Error Log indicator (previously known as the System Information (Attention)
indicator) and Fault indicators are regulated by the following requirements,
among others:</para>
<itemizedlist>
<itemizedlist>
<listitem><para><xref linkend="dbdoclet.50569347_17215"/></para></listitem>

<listitem><para><xref linkend="dbdoclet.50569347_38463"/></para></listitem>
</itemizedlist>
</itemizedlist>
</listitem>
</orderedlist>


@ -23,8 +23,8 @@
<title>Firmware Assisted Dump Data Format</title>

<para>This appendix documents the dump data format, in support of the
Configure Platform Assisted Kernel Dump option in
<xref linkend="LoPAR.Virtualization" />.</para>
Configure Platform Assisted Kernel Dump option
()<xref linkend="dbdoclet.50569332_67111" />).</para>

<section xml:id="dbdoclet.50569380__Ref135446652">
<title>Register Save Area</title>

File diff suppressed because it is too large Load Diff

@ -704,7 +704,7 @@
location of resources) to the processor are preserved by the device tree
once presented upon boot. For a list of properties that may change before
a reboot, see
<xref linkend="LoPAR.RTAS" />.</para>
<xref linkend="dbdoclet.50569332_71049" />.</para>

<variablelist>
<varlistentry>

@ -1710,6 +1710,156 @@
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold"><literal>&#8220;ibm,partition-uuid&#8221;</literal></emphasis></term>
<listitem>
<para>
<emphasis>property name</emphasis> specifies a universally unique identifier for this partition.</para>
<para>
<emphasis>prop-encoded-array</emphasis>: A string of data as described below, encoded as with
<emphasis role="bold">encode-string</emphasis></para>
<para>The Universally Unique IDentifier (UUID) option provides each partition with a
Universally Unique Identifier that is persisted by the platform across partition
reboots, reconfigurations, OS reinstalls, partition migration, hibernation etc.
The UUID is a 16 byte string of format fields and random bits as defined in
<xref linkend="dbdoclet.50569332_20419"/>.</para>
<para>The random bits are generated in an implementation-dependent manner to
achieve a projected probability of collision of not greater than one in 2<superscript>60</superscript>.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569332_20419">
<title>UUID Format</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="25*" />
<colspec colname="c2" colwidth="25*" />
<colspec colname="c3" colwidth="25*" />
<colspec colname="c4" colwidth="25*" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">Field</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Byte:Bit</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Size (Bits)</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Values</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>Version</para>
</entry>
<entry>
<para>0:0</para>
</entry>
<entry>
<para>1</para>
</entry>
<entry>
<para>0: Initial Version</para>
<para>1: Reserved</para>
</entry>
</row>
<row>
<entry>
<para>Random Bits</para>
</entry>
<entry>
<para>0:1 thru 5:7</para>
</entry>
<entry>
<para>47</para>
</entry>
<entry>
<para>Random Bits</para>
</entry>
</row>
<row>
<entry>
<para>Generation Method</para>
</entry>
<entry>
<para>6:0-3</para>
</entry>
<entry>
<para>4</para>
</entry>
<entry>
<para>0b0000 Never Used</para>
<para>0b0100 Random Generated</para>
<para>All other values are reserved</para>
</entry>
</row>
<row>
<entry>
<para>Random Bits</para>
</entry>
<entry>
<para>6:4 - 7:7</para>
</entry>
<entry>
<para>12</para>
</entry>
<entry>
<para>Random Bits</para>
</entry>
</row>
<row>
<entry>
<para>Variant</para>
</entry>
<entry>
<para>8:0-1</para>
</entry>
<entry>
<para>2</para>
</entry>
<entry>
<para>0b10 DCE Variant UUID</para>
<para>All other values are reserved</para>
</entry>
</row>
<row>
<entry>
<para>Random Bits</para>
</entry>
<entry>
<para>8:2 - 15:7</para>
</entry>
<entry>
<para>62</para>
</entry>
<entry>
<para>Random Bits</para>
</entry>
</row>
</tbody>
</tgroup>
</table>


<para>For the GET_PARTNER_UUID subfunction (See <xref linkend="dbdoclet.50569348_62564"/>), the data is
represented as 16 bytes as described in <xref linkend="dbdoclet.50569332_20419"/>.</para>
<para>For the ibm,partition-uuid property, the data is represented as a string of
hexadecimal characters, with hyphens added for readability.
Hexadecimal values a through f are lower case. An example of the string
representation of the UUID is 648a9ca6-1fb4-4f7e-9436-14d015f3dd74</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold"><literal>&#8220;ibm,platform-hardware-notification&#8221;</literal></emphasis></term>
<listitem>
@ -1828,7 +1978,7 @@
<emphasis>prop-encoded-array</emphasis>: An integer encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis> that represents the maximum VIOS level
that the client shall negotiate. See
<xref linkend="LoPAR.Virtualization" /> for the definition of the
<xref linkend="dbdoclet.50569379_75285" /> for the definition of the
values of this property.</para>
</listitem>
</varlistentry>
@ -1962,7 +2112,7 @@
<emphasis>property name</emphasis> to define that the OS may ignore
failures of Hot Plug power off and isolate operations during a DLPAR
remove operation. See also Note 2 in
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569342_17600" />.</para>
<para>
<emphasis>prop-encoded-array</emphasis>: None, this is a name only
property.</para>
@ -2066,6 +2216,28 @@
<para>1 = Platform is operating in the Lightpath mode.</para>
</listitem>
</itemizedlist>

<para>
<emphasis role="bold">Implementation Notes:</emphasis>
</para>

<orderedlist>
<listitem>
<para>In the absence of this property, the determination of how the OS
is to behave is made by the platform presenting or not presenting FRU
Fault indicators to the OS see chapter
<xref linkend="dbdoclet.50569347_31867" />. In the case where there are
no FRUs owned by the partition, the OS will not observe any FRU Fault
indicators assigned, even when the platform is operating in the Lightpath
mode.</para>
</listitem>

<listitem>
<para>Presenting this property does not imply any relaxation of the
requirements specified in chapter
<xref linkend="dbdoclet.50569347_31867" />.</para>
</listitem>
</orderedlist>
</listitem>
</varlistentry>

@ -2090,181 +2262,7 @@
<emphasis>prop-encoded-array</emphasis>: &lt;NULL&gt;</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold"><literal>&#8220;ibm,partition-uuid&#8221;</literal></emphasis></term>
<listitem>
<para>
<emphasis>property name</emphasis> specifies a universally unique identifier for this partition.</para>
<para>
<emphasis>prop-encoded-array</emphasis>: A string of data as described below, encoded as with
<emphasis role="bold">encode-string</emphasis></para>
<para>The Universally Unique IDentifier (UUID) option provides each partition with a
Universally Unique Identifier that is persisted by the platform across partition
reboots, reconfigurations, OS reinstalls, partition migration, hibernation etc.
The UUID is a 16 byte string of format fields and random bits as defined in
<xref linkend="dbdoclet.50569332_20419"/>.</para>
<para>The random bits are generated in an implementation-dependent manner to
achieve a projected probability of collision of not greater than one in 2<superscript>60</superscript>.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569332_20419">
<title>UUID Format</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="25*" />
<colspec colname="c2" colwidth="25*" />
<colspec colname="c3" colwidth="25*" />
<colspec colname="c4" colwidth="25*" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">Field</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Byte:Bit</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Size (Bits)</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Values</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<para>Version</para>
</entry>
<entry>
<para>0:0</para>
</entry>
<entry>
<para>1</para>
</entry>
<entry>
<para>0: Initial Version</para>
<para>1: Reserved</para>
</entry>
</row>
<row>
<entry>
<para>Random Bits</para>
</entry>
<entry>
<para>0:1 thru 5:7</para>
</entry>
<entry>
<para>47</para>
</entry>
<entry>
<para>Random Bits</para>
</entry>
</row>
<row>
<entry>
<para>Generation Method</para>
</entry>
<entry>
<para>6:0-3</para>
</entry>
<entry>
<para>4</para>
</entry>
<entry>
<para>0b0000 Never Used</para>
<para>0b0100 Random Generated</para>
<para>All other values are reserved</para>
</entry>
</row>
<row>
<entry>
<para>Random Bits</para>
</entry>
<entry>
<para>6:4 - 7:7</para>
</entry>
<entry>
<para>12</para>
</entry>
<entry>
<para>Random Bits</para>
</entry>
</row>
<row>
<entry>
<para>Variant</para>
</entry>
<entry>
<para>8:0-1</para>
</entry>
<entry>
<para>2</para>
</entry>
<entry>
<para>0b10 DCE Variant UUID</para>
<para>All other values are reserved</para>
</entry>
</row>
<row>
<entry>
<para>Random Bits</para>
</entry>
<entry>
<para>8:2 - 15:7</para>
</entry>
<entry>
<para>62</para>
</entry>
<entry>
<para>Random Bits</para>
</entry>
</row>
</tbody>
</tgroup>
</table>


<para>For the GET_PARTNER_UUID subfunction (See <xref linkend="LoPAR.Virtualization"/>), the data is
represented as 16 bytes as described in <xref linkend="dbdoclet.50569332_20419"/>.</para>
<para>For the ibm,partition-uuid property, the data is represented as a string of
hexadecimal characters, with hyphens added for readability.
Hexadecimal values a through f are lower case. An example of the string
representation of the UUID is 648a9ca6-1fb4-4f7e-9436-14d015f3dd74</para>
</listitem>
</varlistentry>
</variablelist>

<para>
<emphasis role="bold">Implementation Notes:</emphasis>
</para>


<orderedlist>
<listitem>
<para>In the absence of this property, the determination of how the OS
is to behave is made by the platform presenting or not presenting FRU
Fault indicators to the OS see chapter
<xref linkend="LoPAR.Error" />. In the case where there are
no FRUs owned by the partition, the OS will not observe any FRU Fault
indicators assigned, even when the platform is operating in the Lightpath
mode.</para>
</listitem>

<listitem>
<para>Presenting this property does not imply any relaxation of the
requirements spe3cified in chapter
<xref linkend="LoPAR.Error" />.</para>
</listitem>
</orderedlist>

</section>

<section xml:id="dbdoclet.50569368_10192">
@ -2329,7 +2327,7 @@
<emphasis role="bold"><literal>&#8220;ibm,client-architecture-support&#8221;</literal></emphasis>
and invoke that method with the
<!-- TODO: complete/correct this sentence -->
<emphasis role="bold"><literal>>ibm,???</literal></emphasis> compatible (wording???) with the Real Base and Real Size constraints of the
<emphasis role="bold"><literal>>ibm,???</literal></emphasis> compatible with the Real Base and Real Size constraints of the
kernel being loaded.</para>
</listitem>

@ -3267,7 +3265,7 @@
value indicates that the client supports the I/O Super Page
Option (Support of &gt;4K I/O pages) (Includes extensions to
H_MIGRATE_DMA for &gt;4K I/O pages and &gt;256 xlates).
See <xref linkend="LoPAR.Virtualization" />.</para>
See <xref linkend="dbdoclet.50569344_19308" />.</para>
<para>In the
<emphasis role="bold"><literal>ibm,architecture-vec-5</literal></emphasis> property of the
<emphasis role="bold"><literal>/chosen</literal></emphasis> node, a non-zero value indicates
@ -3287,7 +3285,7 @@
<emphasis role="bold"><literal>/chosen</literal></emphasis> node, this field represents the
implementation dependent number of xlates entries supported per
migration operation as: 256 * 2**N.
See <xref linkend="LoPAR.Virtualization" />.</para>
See <xref linkend="dbdoclet.50569344_19308" />.</para>
</entry>
</row>
<row>
@ -3302,7 +3300,7 @@
<emphasis role="bold"><literal>/chosen</literal></emphasis> node, this field represents the
implementation dependent number of simultaneous migration
options supported as: 2**N.
See <xref linkend="LoPAR.Virtualization" />.</para>
See <xref linkend="dbdoclet.50569344_19308" />.</para>
</entry>
</row>
<row>
@ -3364,7 +3362,7 @@
<para>= the &#8220;Form value&#8221; of the
<emphasis role="bold"><literal>&#8220;ibm,associativity&#8221;</literal></emphasis> and
<emphasis role="bold"><literal>&#8220;ibm,associativity-reference-points&#8221;</literal></emphasis>
properties. See <xref linkend="LoPAR.Platform" /> for further details.</para>
properties. See <xref linkend="dbdoclet.50569346_35960" /> for further details.</para>
</entry>
</row>
<row>
@ -3399,7 +3397,7 @@
<entry>
<para>Enable MTT Option</para>
<para>See
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569344_50921" />.</para>
</entry>
</row>
<row>
@ -3449,7 +3447,7 @@
</entry>
<entry>
<para>Enable Hotplug Interrupts<?linebreak?>
See Hot Plug Events in <xref linkend="LoPAR.Error" />.</para>
See Hot Plug Events in <xref linkend="Hot_Plug_Events" />.</para>
</entry>
</row>
<row>
@ -4388,7 +4386,7 @@
<emphasis>token</emphasis>) for the defined indicators and the number of
indicators (
<emphasis>maxindex</emphasis>) for that token which are implemented (see
<xref linkend="LoPAR.RTAS" />) on the platform.</para>
<xref linkend="dbdoclet.50569332_13537" />) on the platform.</para>
<para>
<emphasis role="bold">Note:</emphasis> The indicator indices for a given token are
numbered 0... maxindex-1.</para>
@ -4410,7 +4408,7 @@
<emphasis>token</emphasis>) for the defined sensors and the number of
sensors (
<emphasis>maxindex</emphasis>) for that token which are implemented (see
<xref linkend="LoPAR.RTAS" />) on the platform.</para>
<xref linkend="dbdoclet.50569332_13537" />) on the platform.</para>
<para>
<emphasis role="bold">Note:</emphasis> The sensor indices for a given token are
numbered 0 ... maxindex-1.</para>
@ -4933,7 +4931,7 @@
<para>
<emphasis>prop-encoded-array</emphasis>: Contains the description of the
registered kernel dump in the format described in
<xref linkend="LoPAR.RTAS" />.</para>
<xref linkend="dbdoclet.50569332_76933" />.</para>
</listitem>
</varlistentry>

@ -4949,7 +4947,7 @@
the first 3 inputs and the first 4 outputs (
<emphasis>Number Inputs</emphasis> is required to be 3 and the
<emphasis>Number Outputs</emphasis> is required to be 4), as defined in
<xref linkend="LoPAR.RTAS" />.</para>
<xref linkend="dbdoclet.50569332_80186" />.</para>
<para>
<emphasis>prop-encoded-array</emphasis>: Contains a 32 bit cell, with the
bits defined as follows:</para>
@ -4958,13 +4956,13 @@
<emphasis>ibm,read-slot-reset-state2</emphasis> RTAS call checks the
<emphasis>Number Outputs</emphasis> and the implements the 5th output (
<emphasis>Number Outputs</emphasis> of 5), as defined by
<xref linkend="LoPAR.RTAS" />.</para>
<xref linkend="dbdoclet.50569332_80186" />.</para>
<para>Bit 31: When a value of 1, the
<emphasis>ibm,read-slot-reset-state2</emphasis> RTAS call implements the
first 3 inputs and the first 4 outputs (
<emphasis>Number Inputs</emphasis> of 3 and the
<emphasis>Number Outputs</emphasis> of 4), as defined in
<xref linkend="LoPAR.RTAS" />. This bit is always required
<xref linkend="dbdoclet.50569332_80186" />. This bit is always required
to be a value of 1 when this property is implemented.</para>
</listitem>
</varlistentry>
@ -5035,7 +5033,7 @@
<para><emphasis>property-name</emphasis> indicating that the platform supports
extended
<emphasis>ibm,os-term</emphasis> behavior as described in
<xref linkend="LoPAR.RTAS" />.</para>
<xref linkend="dbdoclet.50569332_42118" />.</para>
<para><emphasis>prop-encoded-array</emphasis>: encode-null</para>
</listitem>
</varlistentry>
@ -5048,8 +5046,8 @@

<para>This section defines the property names associated with the various
RTAS functions defined by
<xref linkend="LoPAR.RTAS" />.
<xref linkend="LoPAR.RTAS" /> should be used as the reference
<xref linkend="dbdoclet.50569332_20008" />.
<xref linkend="dbdoclet.50569332_20008" /> should be used as the reference
for RTAS Functions currently implemented. Each RTAS function that a
platform implements shall
be represented by its own function property,
@ -5076,7 +5074,7 @@
<emphasis>rtas-call</emphasis> interface (see below), invokes the named
RTAS function. If a RTAS function is not implemented, there will not be a
property corresponding to that function name. See the
<xref linkend="LoPAR.RTAS" /> for more information about RTAS
<xref linkend="dbdoclet.50569332_13537" /> for more information about RTAS
functions.</para>
</listitem>
</varlistentry>
@ -5502,7 +5500,7 @@
<para>The first specification shall specify the configured address and
size of this PHB&#8217;s I/O Space. (I/O Space is shown as
&#8220;BIOn&#8221; to &#8220;TIOn&#8221; in
<xref linkend="LoPAR.Platform" /> "Address Map" section.) The
<xref linkend="dbdoclet.50569328_Address-Map" />.) The
second specification shall specify the configured address and size of
this PHB&#8217;s Memory Space. (Memory Space is shown as
&#8220;BPMn&#8221; to &#8220;TPMn&#8221; in the Common Hardware Reference
@ -5595,7 +5593,7 @@
<para><emphasis>prop-encoded-array</emphasis>: Integer, encoded as with
<emphasis role="bold"><literal>encode-int</literal></emphasis>.</para>
<para>This property, when present (for example, see Requirement
<xref linkend="LoPAR.Platform" />), indicates the maximum DMA
<xref linkend="dbdoclet.50569335_65475" />), indicates the maximum DMA
Read completion latency for IOAs under this PHB, in microseconds. For
plug-in adapters, the latency value does not include latency of any
additional PCI fabric (for example, PCI Express switches) on the plug-in
@ -5974,7 +5972,7 @@
as a token for an additional RTAS call or an architectural level of an
extended interface. The value of one indicates that only a single
extension is implemented as specified by the second integer in the list.
<xref linkend="LoPAR.RTAS" /> provides the definition of the
<xref linkend="dbdoclet.50569332_25585" /> provides the definition of the
subsequent integers as defined for the LoPAR level of the DDW
option.</para>
</listitem>
@ -7452,7 +7450,7 @@
<listitem>
<para><emphasis>property name</emphasis> to provide Vital Product Data (VPD)
information as defined in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569341_29745" />.</para>
<para>
<emphasis>prop-encoded-array</emphasis>: the concatenation, with
<emphasis role="bold"><literal>encode+</literal></emphasis>, of one or more pairs of elements, the first
@ -7831,7 +7829,7 @@

</section>

<section>
<section xml:id="sec_papr_bindings_hot_plug_events">
<title>hot-plug-events</title>

<para>The presence of the node indicates that all or some of the function
@ -8367,7 +8365,7 @@
</tgroup>
</table>
<para>See
<xref linkend="LoPAR.Error" /> for further detail on this
<xref linkend="dbdoclet.50569352_15379" /> for further detail on this
virtual device.</para>
</listitem>
</varlistentry>
@ -8412,7 +8410,7 @@
<emphasis role="bold"><literal>&#8220;reg&#8221;</literal></emphasis> property value. The following
properties are the minimum required, optional support such as dynamic
reconfiguration will add properties per requirements called out in the
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569342_82208" />.</para>

<variablelist>
<varlistentry>
@ -10643,7 +10641,7 @@ where:
power management related information shall be resident in the OF device
tree prior to the transfer phase of software operation (see the
definition of transfer phase in
<xref linkend="LoPAR.Platform" />). Dummy devices shall be
<xref linkend="dbdoclet.50569327_31987" />). Dummy devices shall be
placed in the device tree for all standard I/O bus connectors which are
not in use to provide a node to assign the slot-names, power-domains, and
power-sources properties.</para>

@ -7,7 +7,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>This appendix defines the string that is returned by the
ibm,get-system-parameter RTAS call when the parameter token value of 20
(SPLPAR Characteristics) is specified on the ibm,get-system-parameter RTAS
call as per <xref linkend="LoPAR.RTAS" />.</para>
call as per <xref linkend="dbdoclet.50569332_24237" />.</para>
</section>
<section>
<title>SPLPAR Terms</title>

File diff suppressed because it is too large Load Diff

@ -1,6 +1,9 @@
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title xml:id="dbdoclet.50569342_75822">Dynamic Reconfiguration (DR) Architecture</title>
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0"
xml:lang="en"
xml:id="dbdoclet.50569342_75822">
<title>Dynamic Reconfiguration (DR) Architecture</title>

<para>Dynamic Reconfiguration (DR) is the capability of a system to adapt to
changes in the hardware/firmware physical or logical configuration, and to be
@ -283,7 +286,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<entry>
<para>A DR entity which does not have to be physically plugged or
unplugged during a DR operation on that entity. See
<xref linkend="LoPAR.DeviceTree" /> for a list of the supported
<xref linkend="dbdoclet.50569368_97022" /> for a list of the supported
Logical DR types.</para>
</entry>
</row>
@ -317,7 +320,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<entry>
<para>A DR entity which may need to be physically plugged or
unplugged during a DR operation on that entity. See
<xref linkend="LoPAR.DeviceTree" /> for a list of the supported
<xref linkend="dbdoclet.50569368_97022" /> for a list of the supported
physical DR types.</para>
</entry>
</row>
@ -448,7 +451,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
these operations. In this case, the OS may ignore
those errors if the operation is a DLPAR to remove the
hardware. See also the <emphasis role="bold"><literal>&#8220;ibm,ignore-hp-po-fails-for-dlpar&#8221;</literal></emphasis>
property in <xref linkend="LoPAR.DeviceTree" />.</para>
property in <xref linkend="dbdoclet.50569368_54493" />.</para>
</listitem>
</orderedlist>
</para>
@ -1127,7 +1130,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
connector an index to be passed between the OS and RTAS to identify the
DR connector to be operated upon. This property is in the parent node of
the DR connector to which the property applies. See
<xref linkend="LoPAR.DeviceTree" /> for the definition of this
<xref linkend="dbdoclet.50569368_13582" /> for the definition of this
property. See <xref linkend="sec_ibmdrcinfo_property" /> for additional information.</para>

<variablelist>
@ -1151,7 +1154,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
entry in the
<emphasis role="bold"><literal>&#8220;ibm,drc-indexes&#8221;</literal></emphasis> property for that
connector. This property is used for correlation purposes. See
<xref linkend="LoPAR.DeviceTree" /> for the definition of this
<xref linkend="dbdoclet.50569368_13582" /> for the definition of this
property.</para>

<variablelist>
@ -1172,7 +1175,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title><emphasis role="bold"><literal>&#8220;ibm,drc-names&#8221;</literal></emphasis> Property</title>
<para>This property is added for the DR option to specify for each DR
connector a user-readable location code for the connector. See
<xref linkend="LoPAR.DeviceTree" /> for the definition of this
<xref linkend="dbdoclet.50569368_13582" /> for the definition of this
property. See <xref linkend="sec_ibmdrcinfo_property" /> for additional information.</para>

<variablelist>
@ -1299,7 +1302,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title><emphasis role="bold"><literal>&#8220;ibm,drc-power-domains&#8221;</literal></emphasis> Property</title>
<para>This property is added for the DR option to specify for each DR
connector the power domain in which the connector resides. See
<xref linkend="LoPAR.DeviceTree" /> for the definition of this
<xref linkend="dbdoclet.50569368_13582" /> for the definition of this
property. See <xref linkend="sec_ibmdrcinfo_property" /> for additional information.</para>

<variablelist>
@ -1339,7 +1342,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title><emphasis role="bold"><literal>&#8220;ibm,drc-types&#8221;</literal></emphasis> Property</title>
<para>This property is added for the DR option to specify for each DR
connector a user-readable connector type for the connector. See
<xref linkend="LoPAR.DeviceTree" /> for the definition of this
<xref linkend="dbdoclet.50569368_13582" /> for the definition of this
property. See <xref linkend="sec_ibmdrcinfo_property" /> for additional information.</para>
<para>
<emphasis role="bold">Architecture Note:</emphasis> The logical connectors (CPU, MEM
@ -1369,7 +1372,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title><emphasis role="bold"><literal>&#8220;ibm,phandle&#8221;</literal></emphasis> Property</title>
<para>This property is added for the DR option to specify the phandle for
each OF device tree node returned by ibm,configure-connector. See
<xref linkend="LoPAR.DeviceTree" /> for the definition of this
<xref linkend="dbdoclet.50569368_13582" /> for the definition of this
property.</para>

<variablelist>
@ -1473,7 +1476,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<section xml:id="sec_set_power_level">
<title><emphasis>set-power-level</emphasis></title>
<para>This RTAS call is defined in
<xref linkend="LoPAR.RTAS" />. Several additional requirements are placed
<xref linkend="dbdoclet.50569332_45884" />. Several additional requirements are placed
on this call when the platform implements DR along with PM.</para>
<para>This RTAS call is used in DR to power up or power down a DR
connector, if necessary (that is, if there is a non-zero power domain
@ -1497,7 +1500,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para><emphasis role="bold">For all DR options:</emphasis> the
<emphasis>set-power-level</emphasis> RTAS call must be implemented as
specified in
<xref linkend="LoPAR.RTAS" /> and the further requirements of this DR
<xref linkend="dbdoclet.50569332_45884" /> and the further requirements of this DR
option.</para>
</listitem>
</varlistentry>
@ -1859,7 +1862,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<section xml:id="dbdoclet.50569342_61130">
<title><emphasis>set-indicator</emphasis></title>
<para>This RTAS call is defined as shown in
<xref linkend="LoPAR.RTAS" />. This RTAS call is used in DR to transition
<xref linkend="dbdoclet.50569332_27587" />. This RTAS call is used in DR to transition
between isolation states, allocation states, and control DR indicators.
In some cases, a state transition fails due to various conditions,
however, a null transition (commanding that the new state be what it
@ -2015,7 +2018,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
connector, then they are used to indicate the state of the DR
connector to the user. Usage of these states are as defined in
<xref linkend="dbdoclet.50569342_42695" /> and
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</entry>
</row>
<row>
@ -2074,7 +2077,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<emphasis>set-indicator</emphasis> call must return a -2 status, or
optionally for indicator type 9001 the 990x status, for each call until
the operation is complete; where the 990x status is defined in
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569332_10584" />.</para>
</listitem>
</varlistentry>

@ -2512,7 +2515,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
requirement, in order to provide for a consistent user interface across
platforms. Information on implementation dependent aspects of the DR
indicators can be found in
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>

<variablelist>
<varlistentry>
@ -2557,7 +2560,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
power off at the connector, then the caller of
<emphasis>set-indicator</emphasis> must turn power off prior to
setting the indicator to this state. See also
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</entry>
</row>
<row>
@ -2569,7 +2572,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
identify the physical location of the DR connector. This state
may map to the same visual state (for example, blink rate) as
the Action state, or may map to a different state. See also
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</entry>
</row>
<row>
@ -2581,7 +2584,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
the user is to perform the current DR operation. This state may
map to the same visual state (for example, blink rate) as the
Identify state, or may map to a different state. See also
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</entry>
</row>
<row>
@ -2591,7 +2594,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<entry>
<para>The DR connector is active and entity removal may disrupt
system operation. See also
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</entry>
</row>
</tbody>
@ -2671,7 +2674,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<listitem>
<para>When bringing a DR entity online that
utilizes TCEs (see
<xref linkend="LoPAR.Platform" />), the OS must initialize the DR
<xref linkend="dbdoclet.50569328_76588" />), the OS must initialize the DR
entity's TCEs.</para>
</listitem>
</varlistentry>
@ -2743,7 +2746,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>The other indicator must be amber and must be controllable by
RTAS, separately from all other indicators, and must be used as a slot
Identify indicator, as defined in
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</listitem>
</orderedlist>
</para>
@ -3295,7 +3298,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>Always present for sub-systems and for PCI IOAs which
follow the PCI VPD proposed standard. See
<!-- FIXME: Requirement R1-12.4.2-1-->
<xref linkend="LoPAR.Platform" /> and note to see the effect of
<xref linkend="dbdoclet.50569341_65980" /> and note to see the effect of
using different PCI versions.</para>
</entry>
</row>
@ -3735,7 +3738,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>Shall be one of the values &#8220;CPU&#8221;,
&#8220;MEM&#8221;, &#8220;PHB&#8221;, or &#8220;SLOT&#8221; as
defined in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_97022" />.</para>
</entry>
</row>
<row>
@ -3865,7 +3868,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<emphasis role="bold"><literal>&#8220;ibm,lrdr-capacity&#8221;</literal></emphasis> property must be
included in the
<emphasis role="bold"><literal>/rtas</literal></emphasis> node of the partition device tree (see
<xref linkend="LoPAR.DeviceTree" />).</para>
<xref linkend="dbdoclet.50569368_41461" />).</para>
</listitem>
</varlistentry>
</variablelist>

@ -1,285 +1,285 @@
<?xml version="1.0"?>
<chapter xmlns="http://docbook.org/ns/docbook"
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
xml:id="dbdoclet.50569331_37856"
version="5.0"
version="5.0"
xml:lang="en">
<title>Interrupt Controller</title>
<para>This chapter specifies the requirements for the LoPAR interrupt
controller. Platforms may chose to virtualize the interrupt controller or to

<para>This chapter specifies the requirements for the LoPAR interrupt
controller. Platforms may chose to virtualize the interrupt controller or to
provide the PowerPC External Interrupt option. </para>

<section>
<title>Interrupt Controller Virtualization</title>
<para>Virtualization of the interrupt controller is done through the
Interrupt Support hcalls. See <xref linkend="LoPAR.Virtualization"/>.</para>
<para>Virtualization of the interrupt controller is done through the
Interrupt Support hcalls. See <xref linkend="dbdoclet.50569344_26787"/>.</para>
</section>

<section xml:id="dbdoclet.50569331_29157">
<title>PowerPC External Interrupt Option</title>
<para>The PowerPC External Interrupt option is based upon a subset of the
PowerPC External Interrupt Architecture. The PowerPC External Interrupt
Architecture contains a register-level architectural definition of an interrupt
control structure. This architecture defines means for assigning properties
such as priority, destination, etc., to I/O and interprocessor interrupts, as
well as an interface for presenting them to processors. It supports both
specific and distributed methods for interrupt delivery. See also
<!-- FIXME: xref linkend="error_section"/--><citetitle>A PowerPC External
<para>The PowerPC External Interrupt option is based upon a subset of the
PowerPC External Interrupt Architecture. The PowerPC External Interrupt
Architecture contains a register-level architectural definition of an interrupt
control structure. This architecture defines means for assigning properties
such as priority, destination, etc., to I/O and interprocessor interrupts, as
well as an interface for presenting them to processors. It supports both
specific and distributed methods for interrupt delivery. See also
<!-- FIXME: xref linkend="error_section"/--><citetitle>A PowerPC External
Interrupt</citetitle>.htm#38341.--&gt;</para>
<para>In NUMA platform configurations, the interrupt controllers may be
configured in disjoint domains. The firmware makes the server numbers visible
to any single OS image appear to come from a single space without duplication.
This may be done by appropriately initializing the interrupt presentation
controllers or the firmware may translate the server numbers presented to it in
RTAS calls before entering them into the interrupt controller registers. The OS
is made aware that certain interrupts are only served by certain servers by the
inclusion of the <emphasis role="bold"><literal>&#x201C;ibm,interrupt-domain&#x201D;</literal></emphasis>
<para>In NUMA platform configurations, the interrupt controllers may be
configured in disjoint domains. The firmware makes the server numbers visible
to any single OS image appear to come from a single space without duplication.
This may be done by appropriately initializing the interrupt presentation
controllers or the firmware may translate the server numbers presented to it in
RTAS calls before entering them into the interrupt controller registers. The OS
is made aware that certain interrupts are only served by certain servers by the
inclusion of the <emphasis role="bold"><literal>&#x201C;ibm,interrupt-domain&#x201D;</literal></emphasis>
property in the interrupt controller nodes.</para>

<section xml:id="sec_ext_int_opt_req">
<title>PowerPC External Interrupt Option Requirements</title>
<para>The following are the requirements for the PowerPC External
Interrupt option. Additional requirements and information relative to the MSI
option, when implemented with this option, are listed in <xref
<para>The following are the requirements for the PowerPC External
Interrupt option. Additional requirements and information relative to the MSI
option, when implemented with this option, are listed in <xref
linkend="dbdoclet.50569331_33067"/>.</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Platforms must implement interrupt architectures
that are in register-level architectural compliance with
<!-- FIXME: <xref linkend="error_section"/ --><citetitle>A PowerPC External
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Platforms must implement interrupt architectures
that are in register-level architectural compliance with
<!-- FIXME: <xref linkend="error_section"/ --><citetitle>A PowerPC External
Interrupt</citetitle>. </para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform&#x2019;s OF device tree must include
one or more PowerPC External Interrupt Presentation node(s), as children of the
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform&#x2019;s OF device tree must include
one or more PowerPC External Interrupt Presentation node(s), as children of the
root node.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform&#x2019;s OF device tree must include
an <emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-server#s&#x201D;</literal></emphasis> and an
<emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-gserver#s&#x201D;</literal></emphasis> property as defined for
each processor in the processor&#x2019;s <emphasis role="bold"><literal>/cpus/cpu</literal></emphasis>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform&#x2019;s OF device tree must include
an <emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-server#s&#x201D;</literal></emphasis> and an
<emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-gserver#s&#x201D;</literal></emphasis> property as defined for
each processor in the processor&#x2019;s <emphasis role="bold"><literal>/cpus/cpu</literal></emphasis>
node.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The various
<emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-server#s&#x201D;</literal></emphasis> property values seen by a
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The various
<emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-server#s&#x201D;</literal></emphasis> property values seen by a
single OS image must be all unique.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> If an OS image sees multiple global interrupt
server queues, the <emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-gserver#s&#x201D;</literal></emphasis>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> If an OS image sees multiple global interrupt
server queues, the <emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-gserver#s&#x201D;</literal></emphasis>
properties associated with the various queues must have unique values. </para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform&#x2019;s OF device tree must include
a PowerPC External Interrupt Source Controller node, as defined for each Bus
Unit Controller (BUC) that can generate PowerPC External Interrupt Architecture
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform&#x2019;s OF device tree must include
a PowerPC External Interrupt Source Controller node, as defined for each Bus
Unit Controller (BUC) that can generate PowerPC External Interrupt Architecture
interrupts, as a child of the platform&#x2019;s root node.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform&#x2019;s OF device tree must conform
to the <emphasis><xref linkend="dbdoclet.50569387_40740"/></emphasis> and
include the appropriate mapping and interrupt properties to allow the mapping
of all non-zero XISR values (<emphasis>interrupt#</emphasis>) to the
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform&#x2019;s OF device tree must conform
to the <emphasis><xref linkend="dbdoclet.50569387_40740"/></emphasis> and
include the appropriate mapping and interrupt properties to allow the mapping
of all non-zero XISR values (<emphasis>interrupt#</emphasis>) to the
corresponding node generating the interrupt. </para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The PowerPC External Interrupt Presentation
Controller node must not contain the
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The PowerPC External Interrupt Presentation
Controller node must not contain the
<emphasis role="bold"><literal>&#x201C;used-by-rtas&#x201D;</literal></emphasis> property. </para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The PowerPC External Interrupt Source Controller
node must contain the <emphasis role="bold"><literal>&#x201C;used-by-rtas&#x201D;</literal></emphasis>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The PowerPC External Interrupt Source Controller
node must contain the <emphasis role="bold"><literal>&#x201C;used-by-rtas&#x201D;</literal></emphasis>
property.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-10.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> If the interrupt hardware is configured such that,
viewed from any given OS image, any interrupt source controller cannot direct
interrupts to any interrupt presentation controller, then the platform must
include the <emphasis role="bold"><literal>&#x201C;ibm,interrupt-domain&#x201D;</literal></emphasis> property
in all interrupt source and presentation controller nodes for that OS so that
the OS can determine the servers that may be valid targets for any given
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> If the interrupt hardware is configured such that,
viewed from any given OS image, any interrupt source controller cannot direct
interrupts to any interrupt presentation controller, then the platform must
include the <emphasis role="bold"><literal>&#x201C;ibm,interrupt-domain&#x201D;</literal></emphasis> property
in all interrupt source and presentation controller nodes for that OS so that
the OS can determine the servers that may be valid targets for any given
interrupt.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-11.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> All interrupt controller registers must be
accessed via Caching-Inhibited, Memory Coherence not required and Guarded
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> All interrupt controller registers must be
accessed via Caching-Inhibited, Memory Coherence not required and Guarded
Storage mapping.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-12.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform must manage the Available Processor
Mask Register so that global interrupts (server number field of the eXternal
Interrupt Vector Entry (XIVE) set to a value from
<emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-gserver#s&#x201D;</literal></emphasis>) are only sent to one
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform must manage the Available Processor
Mask Register so that global interrupts (server number field of the eXternal
Interrupt Vector Entry (XIVE) set to a value from
<emphasis role="bold"><literal>&#x201C;ibm,ppc-interrupt-gserver#s&#x201D;</literal></emphasis>) are only sent to one
of the active processors.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-13.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform must initialize the interrupt
priority in each XIVE to the least favored level (0xFF), enable any associated
IER bit for interrupt sources owned by the OS, and set the Current Processor
Priority Register to the Most favored level (0x00) prior to the transfer of
control to the OS so that no interrupts are signaled to a processor until the
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform must initialize the interrupt
priority in each XIVE to the least favored level (0xFF), enable any associated
IER bit for interrupt sources owned by the OS, and set the Current Processor
Priority Register to the Most favored level (0x00) prior to the transfer of
control to the OS so that no interrupts are signaled to a processor until the
OS has taken explicit action.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-14.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Any implemented PowerPC External Interrupt
Architecture registers that are not reported in specific interrupt source or
destination controller nodes (such as the APM register) must be included in the
<emphasis role="bold"><literal>&#x201C;reg&#x201D;</literal></emphasis> property of the
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Any implemented PowerPC External Interrupt
Architecture registers that are not reported in specific interrupt source or
destination controller nodes (such as the APM register) must be included in the
<emphasis role="bold"><literal>&#x201C;reg&#x201D;</literal></emphasis> property of the
<emphasis>/reserved</emphasis> node.</para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569331_84135">
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-15.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The interrupt source controller must prevent signalling new
interrupts when the XIVE interrupt priority field is set to the least favored
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The interrupt source controller must prevent signalling new
interrupts when the XIVE interrupt priority field is set to the least favored
level.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-16.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Interrupt controllers that do not implement the
behavior of Requirement <xref linkend="dbdoclet.50569331_84135"/>, must provide
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Interrupt controllers that do not implement the
behavior of Requirement <xref linkend="dbdoclet.50569331_84135"/>, must provide
an Interrupt Enable Register (IER) which can be manipulated by RTAS, </para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-17.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform must assign the Bus Unit Identifiers
(BUIDs) such that they form a compact address space. That is, while the first
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> The platform must assign the Bus Unit Identifiers
(BUIDs) such that they form a compact address space. That is, while the first
BUID value is arbitrary, subsequent BUIDs should be contiguous.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-18.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Platforms implementing interrupt server number
fields greater than 8 bits must include the
<emphasis role="bold"><literal>&#x201C;ibm,interrupt-server#-size&#x201D;</literal></emphasis> property in the interrupt
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Platforms implementing interrupt server number
fields greater than 8 bits must include the
<emphasis role="bold"><literal>&#x201C;ibm,interrupt-server#-size&#x201D;</literal></emphasis> property in the interrupt
source controller node.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-19.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Platforms implementing interrupt buid number
fields greater than 9 bits must include the
<emphasis role="bold"><literal>&#x201C;ibm,interrupt-buid-size&#x201D;</literal></emphasis> property in the interrupt
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Platforms implementing interrupt buid number
fields greater than 9 bits must include the
<emphasis role="bold"><literal>&#x201C;ibm,interrupt-buid-size&#x201D;</literal></emphasis> property in the interrupt
presentation controller node.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
<term><emphasis role="bold">R1-<xref linkend="sec_ext_int_opt_req"
xrefstyle="select: labelnumber nopage"/>-20.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Platforms must include the
<emphasis role="bold"><literal>&#x201C;ibm,interrupt-server-ranges&#x201D;</literal></emphasis> property in the
<para><emphasis role="bold">For the PowerPC External
Interrupt option:</emphasis> Platforms must include the
<emphasis role="bold"><literal>&#x201C;ibm,interrupt-server-ranges&#x201D;</literal></emphasis> property in the
interrupt presentation controller node.</para>
</listitem>
</varlistentry>
@ -289,42 +289,42 @@ xml:lang="en">

<section>
<title>PowerPC External Interrupt Option Properties</title>
<para>See <xref linkend="LoPAR.DeviceTree"/> for property definitions.</para>
<para>See <xref linkend="dbdoclet.50569368_91814"/> for property definitions.</para>
</section>

<section xml:id="dbdoclet.50569331_33067">
<title>MSI Option</title>
<para>The Message Signaled Interrupt (MSI) or Enhanced MSI (MSI-X)
capability of PCI IOAs in many cases allows for greater flexibility in
assignment of external interrupts to IOA functions than the predecessor Level
Sensitive Interrupt (LSI) capability, and in some cases treats MSIs as a
resource pool that can be reassigned based on availability of MSIs and the need
of an IOA function for more interrupts than initially assigned. Platforms that
implement the MSI option implement the <emphasis>ibm,change-msi</emphasis> and
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS calls. These RTAS
calls manage interrupts in a platform that implements the MSI option. In
particular, these calls assign additional MSI resources to an IOA function (as
defined by its PCI configuration address: <emphasis>PHB_Unit_ID_Hi,
PHB_Unit_ID_Low, and config_addr</emphasis>), when supported by the platform.
See <xref linkend="LoPAR.RTAS"/> for more information on theses RTAS calls for
<para>The Message Signaled Interrupt (MSI) or Enhanced MSI (MSI-X)
capability of PCI IOAs in many cases allows for greater flexibility in
assignment of external interrupts to IOA functions than the predecessor Level
Sensitive Interrupt (LSI) capability, and in some cases treats MSIs as a
resource pool that can be reassigned based on availability of MSIs and the need
of an IOA function for more interrupts than initially assigned. Platforms that
implement the MSI option implement the <emphasis>ibm,change-msi</emphasis> and
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS calls. These RTAS
calls manage interrupts in a platform that implements the MSI option. In
particular, these calls assign additional MSI resources to an IOA function (as
defined by its PCI configuration address: <emphasis>PHB_Unit_ID_Hi,
PHB_Unit_ID_Low, and config_addr</emphasis>), when supported by the platform.
See <xref linkend="dbdoclet.50569332_61719"/> for more information on theses RTAS calls for
MSI management.</para>
<para>This architecture will refer generically to the MSI and MSI-X
capabilities as simply &#x201C;MSI,&#x201D; except where differentiation is
required. In this architecture, MSIs and LSIs are what the IOA function
signals, and what the software sees for that signal is ultimately the LSI or
MSI <emphasis>source number</emphasis>. The interrupt source numbers returned
by the <emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call are
<para>This architecture will refer generically to the MSI and MSI-X
capabilities as simply &#x201C;MSI,&#x201D; except where differentiation is
required. In this architecture, MSIs and LSIs are what the IOA function
signals, and what the software sees for that signal is ultimately the LSI or
MSI <emphasis>source number</emphasis>. The interrupt source numbers returned
by the <emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call are
the numbers used to control the interrupt as in the <emphasis>ibm,get-xive</emphasis>,
<emphasis>ibm,set-xive</emphasis>, <emphasis>ibm,int-on</emphasis>,
<emphasis>ibm,set-xive</emphasis>, <emphasis>ibm,int-on</emphasis>,
and <emphasis>ibm,int-off</emphasis> RTAS calls.</para>
<para>PCI-X and PCI Express IOA functions that signal interrupts are
required by the PCI specifications to implement either the MSI or MSI-X
interrupt capabilities, or both. For PCI Express, it is expected that IOAs will
only support MSI or MSI-X (that is, no support for LSIs). When both MSI and
MSI-X are implemented by an IOA function, the MSI method will be configured by
the platform, but may be overridden by the OS or device driver, via the
<emphasis>ibm,change-msi</emphasis> RTAS call, to be MSI-X or, if assigned by
the firmware, to LSI (by removal of the MSIs assigned).
<para>PCI-X and PCI Express IOA functions that signal interrupts are
required by the PCI specifications to implement either the MSI or MSI-X
interrupt capabilities, or both. For PCI Express, it is expected that IOAs will
only support MSI or MSI-X (that is, no support for LSIs). When both MSI and
MSI-X are implemented by an IOA function, the MSI method will be configured by
the platform, but may be overridden by the OS or device driver, via the
<emphasis>ibm,change-msi</emphasis> RTAS call, to be MSI-X or, if assigned by
the firmware, to LSI (by removal of the MSIs assigned).
<xref linkend="dbdoclet.50569331_99447"/> summarizes the LSI and MSI support.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569331_99447">
@ -366,9 +366,9 @@ xml:lang="en">
</entry>
<entry morerows="1">
<para>
<emphasis role="bold">Initial interrupt assignment<footnote
xml:id="pgfId-1012212"><para>Assignment means to allocate the platform
resources and to enable the interrupt in the IOA function&#x2019;s
<emphasis role="bold">Initial interrupt assignment<footnote
xml:id="pgfId-1012212"><para>Assignment means to allocate the platform
resources and to enable the interrupt in the IOA function&#x2019;s
configuration space.</para></footnote></emphasis>
</para>
</entry>
@ -406,8 +406,8 @@ xml:lang="en">
<para>LSI or MSI</para>
</entry>
<entry>
<para>LSI<footnote xml:id="pgfId-1001089"><para>If MSIs are to
be supported, the device driver must enable via the
<para>LSI<footnote xml:id="pgfId-1001089"><para>If MSIs are to
be supported, the device driver must enable via the
<emphasis>ibm,change-msi</emphasis> RTAS call.</para></footnote></para>
</entry>
</row>
@ -416,7 +416,7 @@ xml:lang="en">
<para>PCI-X</para>
</entry>
<entry>
<para>Encouraged when interrupts are required, for backward
<para>Encouraged when interrupts are required, for backward
platform compatibility</para>
</entry>
<entry>
@ -432,8 +432,8 @@ xml:lang="en">
<para>LSI or MSI</para>
</entry>
<entry>
<para>LSI<footnote xml:id="pgfId-1001101"><para>If MSIs are to
be supported, the device driver must enable via the
<para>LSI<footnote xml:id="pgfId-1001101"><para>If MSIs are to
be supported, the device driver must enable via the
<emphasis>ibm,change-msi</emphasis> RTAS call.</para></footnote></para>
</entry>
</row>
@ -458,11 +458,11 @@ xml:lang="en">
<para>MSI</para>
</entry>
<entry>
<para>MSI<footnote xml:id="pgfId-1012199"><para>MSI as an
initial assignment means that one or more MSIs are reported as being available
for the IOA function. In addition, LSIs may also be reported but not enabled,
in which case if the device driver removes the assigned MSIs, the assigned LSI
are enabled by the platform firmware in the IOA function&#x2019;s configuration
<para>MSI<footnote xml:id="pgfId-1012199"><para>MSI as an
initial assignment means that one or more MSIs are reported as being available
for the IOA function. In addition, LSIs may also be reported but not enabled,
in which case if the device driver removes the assigned MSIs, the assigned LSI
are enabled by the platform firmware in the IOA function&#x2019;s configuration
space.</para></footnote></para>
</entry>
</row>
@ -473,24 +473,24 @@ xml:lang="en">
</entry>
<entry>
<para>LSI or not supported<footnote xml:id="pgfId-1001611">
<para>If PCI Express IOA function does not support LSI,
<para>If PCI Express IOA function does not support LSI,
then this combination is not supported.</para></footnote></para>
</entry>
<entry>
<para>LSI<footnote xml:id="pgfId-1001616">
<para>If PCI Express
IOA function does not support LSI, then this combination is not
<para>If PCI Express
IOA function does not support LSI, then this combination is not
supported.</para></footnote> or MSI</para>
</entry>
<entry>
<para>LSI<footnote xml:id="pgfId-1001598">
<para>If the PCI
Express IOA function does not support LSI, then the platform will set the
initial interrupt assignment to MSI, and if the device driver does not support
MSI, then the IOA function will not be configurable (that is, conversion from
MSI to LSI through the bridge is not supported by this architecture). If LSI is
the initial assignment, then if MSIs are to be supported, device driver must
enable via the <emphasis>ibm,change-msi</emphasis> RTAS
<para>If the PCI
Express IOA function does not support LSI, then the platform will set the
initial interrupt assignment to MSI, and if the device driver does not support
MSI, then the IOA function will not be configurable (that is, conversion from
MSI to LSI through the bridge is not supported by this architecture). If LSI is
the initial assignment, then if MSIs are to be supported, device driver must
enable via the <emphasis>ibm,change-msi</emphasis> RTAS
call.</para></footnote></para>
</entry>
</row>
@ -498,191 +498,191 @@ xml:lang="en">
</tgroup>
</table>

<para>The <emphasis>ibm,change-msi</emphasis> RTAS call is used to query
the initial number of MSIs assigned to a PCI configuration address and to
request a change in the number of MSIs assigned. The MSIs interrupt source
numbers assigned to an IOA function are returned via the
<emphasis>ibm,query-interrupt-source-number</emphasis>
RTAS call. In addition, when the
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call is
implemented, it may be used to query the LSI source numbers, also. The
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call is called
iteratively, once for each interrupt assigned to the IOA function. When an IOA
function receives an initial assignment of an LSI, the interrupt number for
that LSI may also be obtained through the same OF device tree properties that
are used to report interrupt information when the
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call is not
<para>The <emphasis>ibm,change-msi</emphasis> RTAS call is used to query
the initial number of MSIs assigned to a PCI configuration address and to
request a change in the number of MSIs assigned. The MSIs interrupt source
numbers assigned to an IOA function are returned via the
<emphasis>ibm,query-interrupt-source-number</emphasis>
RTAS call. In addition, when the
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call is
implemented, it may be used to query the LSI source numbers, also. The
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call is called
iteratively, once for each interrupt assigned to the IOA function. When an IOA
function receives an initial assignment of an LSI, the interrupt number for
that LSI may also be obtained through the same OF device tree properties that
are used to report interrupt information when the
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call is not
implemented.</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>The platform must implement the MSI
<para>The platform must implement the MSI
option if the platform contains at least one PCI Express HB.</para>
<para><emphasis role="bold">Architecture and Software Note:</emphasis> The MSI
option may also be implemented in the absence of any PCI Express HBs. In that
case, the implementation of the MSI option is via the presence of the
implementation of the associated <emphasis>ibm,change-msi</emphasis> and
<para><emphasis role="bold">Architecture and Software Note:</emphasis> The MSI
option may also be implemented in the absence of any PCI Express HBs. In that
case, the implementation of the MSI option is via the presence of the
implementation of the associated <emphasis>ibm,change-msi</emphasis> and
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS calls.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option:</emphasis>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must implement the PowerPC External Interrupt option.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must implement the <emphasis>ibm,change-msi</emphasis>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must implement the <emphasis>ibm,change-msi</emphasis>
and <emphasis>ibm,query-interrupt-source-number</emphasis> RTAS calls.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must initially assign LSI or MSIs to IOA functions as
defined in <xref linkend="dbdoclet.50569331_99447"/> and must enable the
assigned interrupts in the IOA function&#x2019;s configuration space (the
interrupts remains disabled at the PHB, and must be enabled by the device
driver though the <emphasis>ibm,set-xive</emphasis> and
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must initially assign LSI or MSIs to IOA functions as
defined in <xref linkend="dbdoclet.50569331_99447"/> and must enable the
assigned interrupts in the IOA function&#x2019;s configuration space (the
interrupts remains disabled at the PHB, and must be enabled by the device
driver though the <emphasis>ibm,set-xive</emphasis> and
<emphasis>ibm,int-on</emphasis> RTAS calls.</para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569331_84312">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform
must provide a minimum of one MSI per IOA function (that is per each unique PCI
configuration address, including the Function #) to be supported beneath the
interrupt source controller, and any given MSI and MSI source number must not
be shared between functions or within one function (even within the same
The platform
must provide a minimum of one MSI per IOA function (that is per each unique PCI
configuration address, including the Function #) to be supported beneath the
interrupt source controller, and any given MSI and MSI source number must not
be shared between functions or within one function (even within the same
PE).</para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569331_63544">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform
must provide at least one MSI port (the address written by the MSI) per
The platform
must provide at least one MSI port (the address written by the MSI) per
Partitionable Endpoint (PE).</para>
<para><emphasis role="bold">Platform Implementation Note:</emphasis> Requirement
<xref linkend="dbdoclet.50569331_84312"/> in conjunction with Requirement <xref
linkend="dbdoclet.50569331_63544"/> may have certain ramifications on the
design. Depending on the implementation, a unique MSI port per IOA function may
<para><emphasis role="bold">Platform Implementation Note:</emphasis> Requirement
<xref linkend="dbdoclet.50569331_84312"/> in conjunction with Requirement <xref
linkend="dbdoclet.50569331_63544"/> may have certain ramifications on the
design. Depending on the implementation, a unique MSI port per IOA function may
be required, and not just a unique port per PE.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option with the
LPAR option:</emphasis> The platform must prevent a PE from creating an
interrupt to a partition other than those to which the PE is authorized by the
<para><emphasis role="bold">For the MSI option with the
LPAR option:</emphasis> The platform must prevent a PE from creating an
interrupt to a partition other than those to which the PE is authorized by the
platform to interrupt.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must set the PCI configuration space MSI registers properly in an
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must set the PCI configuration space MSI registers properly in an
IOA at all the following times:</para>

<orderedlist numeration="loweralpha">
<orderedlist numeration="loweralpha">
<listitem>
<para>Initial boot time</para>
</listitem>

<listitem>
<para>During the <emphasis>ibm,configure-connector</emphasis> RTAS
<para>During the <emphasis>ibm,configure-connector</emphasis> RTAS
call</para>
</listitem>

<listitem>
<para>During the <emphasis>ibm,change-msi</emphasis> or
<para>During the <emphasis>ibm,change-msi</emphasis> or
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call</para>
</listitem>
</orderedlist>
</orderedlist>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must initialize any bridges necessary to appropriately route
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must initialize any bridges necessary to appropriately route
interrupts at all the following times:</para>

<orderedlist numeration="loweralpha">
<orderedlist numeration="loweralpha">
<listitem>
<para>At initial boot time</para>
</listitem>

<listitem>
<para>During the <emphasis>ibm,configure-connector</emphasis> RTAS
<para>During the <emphasis>ibm,configure-connector</emphasis> RTAS
call</para>
</listitem>

<listitem>
<para>During the <emphasis>ibm,configure-bridge</emphasis> RTAS
<para>During the <emphasis>ibm,configure-bridge</emphasis> RTAS
call</para>
</listitem>

<listitem>
<para>During the <emphasis>ibm,change-msi</emphasis> or
<para>During the <emphasis>ibm,change-msi</emphasis> or
<emphasis>ibm,query-interrupt-source-number</emphasis> RTAS call</para>
</listitem>
</orderedlist>
</orderedlist>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-10.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must provide the <emphasis role="bold"><literal>&#x201C;ibm,req#msi&#x201D;</literal></emphasis>
property for any IOA function which is
requesting MSIs; at initial boot time and during the
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform must provide the <emphasis role="bold"><literal>&#x201C;ibm,req#msi&#x201D;</literal></emphasis>
property for any IOA function which is
requesting MSIs; at initial boot time and during the
<emphasis>ibm,configure-connector</emphasis> RTAS call.</para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569331_62532">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569331_33067"
xrefstyle="select: labelnumber nopage"/>-11.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the MSI option:</emphasis>
The platform
must remember and recover on error recovery any previously allocated and setup
The platform
must remember and recover on error recovery any previously allocated and setup
interrupt information in the platform-owned hardware.</para>
<para><emphasis role="bold">Software and Platform Implementation Note:</emphasis> In
Requirement <xref linkend="dbdoclet.50569331_62532"/>, it is possible that some
interrupts may be lost as part of the error recovery, and software should be
<para><emphasis role="bold">Software and Platform Implementation Note:</emphasis> In
Requirement <xref linkend="dbdoclet.50569331_62532"/>, it is possible that some
interrupts may be lost as part of the error recovery, and software should be
implemented to take into consideration that possibility.</para>
</listitem>
</varlistentry>
@ -693,30 +693,30 @@ xml:lang="en">

<section xml:id="sec_plat_rsvd_int_opt">
<title>Platform Reserved Interrupt Priority Level Option</title>
<para>The Platform Reserved Interrupt Priority Level option allows
platforms to reserve interrupt priority levels for internal uses. When the
platform exercises this option, it notifies the client program via the OF
device tree <emphasis role="bold"><literal>&#x201C;ibm,plat-res-int-priorities&#x201D;</literal></emphasis>
<para>The Platform Reserved Interrupt Priority Level option allows
platforms to reserve interrupt priority levels for internal uses. When the
platform exercises this option, it notifies the client program via the OF
device tree <emphasis role="bold"><literal>&#x201C;ibm,plat-res-int-priorities&#x201D;</literal></emphasis>
property of the <emphasis role="bold"><literal>root</literal></emphasis> node of the device tree.</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_plat_rsvd_int_opt"
<term><emphasis role="bold">R1-<xref linkend="sec_plat_rsvd_int_opt"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the Platform Reserved
Interrupt Priority Level option: The platform must include
the</emphasis><emphasis role="bold"><literal>&#x201C;ibm,plat-res-int-priorities&#x201D;</literal></emphasis>
<para><emphasis role="bold">For the Platform Reserved
Interrupt Priority Level option: The platform must include
the</emphasis><emphasis role="bold"><literal>&#x201C;ibm,plat-res-int-priorities&#x201D;</literal></emphasis>
property in the <emphasis role="bold"><literal>root</literal></emphasis> node of the device tree.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_plat_rsvd_int_opt"
<term><emphasis role="bold">R1-<xref linkend="sec_plat_rsvd_int_opt"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the Platform Reserved
Interrupt Priority Level option:</emphasis> The platform must not reserve
<para><emphasis role="bold">For the Platform Reserved
Interrupt Priority Level option:</emphasis> The platform must not reserve
priority levels 0x00 through 0x07 and 0xFF for internal use. </para>
</listitem>
</varlistentry>

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

@ -211,7 +211,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<title>I/O Sub-System Requirements</title>
<para>The platform divides the I/O subsystem up into Partitionable
Endpoints (PEs). See
<xref linkend="LoPAR.Platform" /> for more information on PEs. Each PE has
<xref linkend="dbdoclet.50569330_34831" /> for more information on PEs. Each PE has
its own (separate) error, addressing, and interrupt domains which allows
the assignment of separate PEs to different LPAR partitions.</para>
<para>The following are the requirements for I/O subsystems when the
@ -2034,7 +2034,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<listitem>
<para><emphasis role="bold">For the LPAR option:</emphasis> If a platform reports in its
<emphasis role="bold"><literal>&#8220;ibm,hypertas-functions&#8221;</literal></emphasis> property (see
<xref linkend="LoPAR.RTAS" />) that it supports a function set, then it
<xref linkend="dbdoclet.50569368_41461" />) that it supports a function set, then it
must support all hcall()s of that function set as defined in
<xref linkend="dbdoclet.50569344_49986" />.</para>
</listitem>
@ -6190,7 +6190,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
using 64 bit linkage conventions and apply to all page sizes that the
platform supports as specified by the
<emphasis role="bold"><literal>&#8220;ibm,processor-page-sizes&#8221;</literal></emphasis> property. (See
<xref linkend="LoPAR.DeviceTree" /> for more details.)
<xref linkend="dbdoclet.50569374_59715" /> for more details.)
The Page actual size is encoded in the PFT entry
per the <xref linkend="dbdoclet.50569387_99718" /> architecture Book IIIs along with the
segment base page size per the <xref linkend="dbdoclet.50569387_99718" />
@ -6463,7 +6463,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
logical region supports (see
<emphasis role="bold"><literal>&#8220;ibm,dynamic-memory&#8221;</literal></emphasis> and
<emphasis role="bold"><literal>&#8220;ibm,lmb-page-sizes&#8221;</literal></emphasis> in
<xref linkend="LoPAR.DeviceTree" /> as well as
<xref linkend="dbdoclet.50569368_91814" /> as well as
<xref linkend="dbdoclet.50569344_65610" /> for more details).</para>
</listitem>
</varlistentry>
@ -6487,7 +6487,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<para><emphasis role="bold">For the LPAR option:</emphasis>
Each logical region must support all page sizes presented in the
<emphasis role="bold"><literal>&#8220;ibm,processor-page-sizes&#8221;</literal></emphasis> property in
<xref linkend="LoPAR.DeviceTree" /> that are less than or equal to the
<xref linkend="dbdoclet.50569374_59715" /> that are less than or equal to the
size of the logical region as specified by either the OF standard
<emphasis role="bold"><literal>&#8220;reg&#8221;</literal></emphasis> property of the logical
region&#8217;s OF
@ -6495,7 +6495,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<emphasis role="bold"><literal>&#8220;ibm,lmb-size&#8221;</literal></emphasis> property of the logical
region&#8217;s
<emphasis role="bold"><literal>/ibm,dynamic-reconfiguration-memory</literal></emphasis> node in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>

<para><emphasis role="bold">Implementation Note:</emphasis> 32 bit versions of AIX only support 36 bit
logical address memory spaces. Providing such a partition with a larger
@ -7883,7 +7883,7 @@ hcall ( const int64 H_BULK_REMOVE, /* Function Code */
fewer than 8 entries for a given actual page size / base page
size combination as communicated by the “Block Invalidate
Characteristics” system parameter (see
<xref linkend="LoPAR.RTAS" />).
<xref linkend="sec_tlb_block_invalidate" />).
The virtual pages are all within
the same naturally aligned 8 page virtual address block and
have the same page and segment size encodings. The AVA parameter,
@ -8648,7 +8648,7 @@ hcall ( const int64 H_RESIZE_HPT_COMMIT, /* Function Code */
<emphasis role="bold"><literal>&#8220;ibm,dma-window&#8221;</literal></emphasis> property associated with
the particular IOA. For the format of the
<emphasis role="bold"><literal>&#8220;ibm,dma-window&#8221;</literal></emphasis> property, reference
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>

<section xml:id="dbdoclet.50569344_38645">
<title>H_GET_TCE</title>
@ -8710,7 +8710,7 @@ hcall ( const uint64 H_GET_TCE, /* Return the contents of the specified TCE */

<listitem>
<para>If specified TCE&#8217;s Page Mapping and Control bits (see
<xref linkend="LoPAR.Platform" />) specify &#8220;Page Fault&#8221; then
<xref linkend="dbdoclet.50569328_76588" />) specify &#8220;Page Fault&#8221; then
return H_Success</para>
</listitem>

@ -8783,7 +8783,7 @@ hcall ( const uint64 H_PUT_TCE, /* Function Token */
<listitem>
<para>If the Page Mapping and Control field of the TCE is not
&#8220;Page Fault&#8221; (see
<xref linkend="LoPAR.Platform" />)</para>
<xref linkend="dbdoclet.50569328_76588" />)</para>

<itemizedlist>
<listitem>
@ -8882,7 +8882,7 @@ hcall ( const uint64 H_STUFF_TCE, /* Function Token */
<listitem>
<para>If the Page Mapping and Control field of the TCE is not
&#8220;Page Fault&#8221; (see
<xref linkend="LoPAR.Platform" />)</para>
<xref linkend="dbdoclet.50569328_76588" />)</para>

<itemizedlist>
<listitem>
@ -9136,7 +9136,7 @@ hcall ( const uint64 H_PUT_TCE_INDIRECT, /* Function Token */
<listitem>
<para>If the Page Mapping and Control field of the 8 byte entry
&#8220;T&#8221; is not &#8220;Page Fault&#8221; (see
<xref linkend="LoPAR.Platform" />) then do</para>
<xref linkend="dbdoclet.50569328_91476" />) then do</para>

<itemizedlist>
<listitem>
@ -10314,7 +10314,7 @@ hcall ( const uint64 H_CLEAR_HPT);]]></programlisting>
<literal>/chosen</literal>
<emphasis role="bold"><literal>&#8220;ibm,architecture-vec&#8221;</literal></emphasis> Byte 23 bits 0-1 undefined or 0b00<footnote xml:id="fn_cas_option_vec_p9">
<para>See ibm,architecture vector 5, byte 23 in
<xref linkend="LoPAR.DeviceTree" />
<xref linkend="dbdoclet.50569368_10077" />
for more details.
</para>
</footnote>
@ -12314,7 +12314,7 @@ hcall ( const uint64 H_INT_RESET, /* Reset all interrupt structures */
returns; this requires that the OS not reuse/modify the data within the
old page until the worst case DMA read access time has expired. The
<emphasis role="bold"><literal>&#8220;ibm,dma-delay-time&#8221;</literal></emphasis> property (see
<xref linkend="LoPAR.DeviceTree" />) gives the OS this implementation
<xref linkend="dbdoclet.50569368_41461" />) gives the OS this implementation
dependent delay value. Failure to observe this delay time may result in
data corruption as seen by the caller&#8217;s I/O adapter(s).</para>

@ -15913,7 +15913,7 @@ hcall ( const uint64 H_GET_DMA_XLATES_LIMITED, /*Return I/O Bus and correspondin
performed, resulting in a constrained return from such a request.</para>
<para>System Parameters readable via the
<emphasis>ibm,get-system-parameter</emphasis> RTAS call (see
<xref linkend="LoPAR.RTAS" />)
<xref linkend="dbdoclet.50569332_62190" />)
communicate a variety of configuration and
constraint parameters among which are determined by the partition
definition.</para>
@ -16742,7 +16742,7 @@ hcall ( const uint64 H_PROD, /* Mark the target processor runable */
<listitem>
<para>When the value of the
<emphasis role="bold"><literal>&#8220;ibm,partition-performance-parameters-level&#8221;</literal></emphasis> see
<xref linkend="LoPAR.DeviceTree" />) is &gt;=1 then register R8 contains
<xref linkend="dbdoclet.50569368_54493" />) is &gt;=1 then register R8 contains
the processor virtualization resource allocations. In the case of a
dedicated processor partition R8 contains 0:</para>

@ -16922,7 +16922,7 @@ hcall ( const uint64 H_SET_PPP, /* Modifies the specified partitions performa
running on processors that do not implement the register in hardware,
firmware simulates the function. On platforms that present the property
<emphasis role="bold"><literal>&#8220;ibm,rks-hcalls&#8221;</literal></emphasis> with bit 2 set (see
<xref linkend="LoPAR.DeviceTree" />), this call provides a reduced
<xref linkend="dbdoclet.50569368_41461" />), this call provides a reduced
&#8220;kill set&#8221; of volatile registers, GPRs r0 and r5-r13 are
preserved.</para>

@ -17086,7 +17086,7 @@ hcall ( const uint64 H_PIC ); /*Returns in R4 the value of the Pool Idle Count *
<listitem>
<para>When the value of the
<emphasis role="bold"><literal>&#8220;ibm,partition-performance-parameters-level&#8221;</literal></emphasis> (see
<xref linkend="LoPAR.DeviceTree" />) is &gt;=1 then:</para>
<xref linkend="dbdoclet.50569368_54493" />) is &gt;=1 then:</para>

<itemizedlist>
<listitem>
@ -17338,7 +17338,7 @@ hcall ( const uint64 H_JOIN /* Join active threads and return H_CONTINUE to fina
<para><emphasis role="bold">For the Virtual Processor Home Node option:</emphasis> The
platform must support the &#8220;Form 1&#8221; of the
<emphasis role="bold"><literal>&#8220;ibm,associativity-reference-points&#8221;</literal></emphasis> property per
<xref linkend="LoPAR.Platform" />. The client program may call
<xref linkend="dbdoclet.50569346_82008" />. The client program may call
H_HOME_NODE_ASSOCIATIVITY hcall() with a valid identifier input parameter
(such as from the device tree or from the
<emphasis>ibm,configure-connector</emphasis> RTAS call) even if the
@ -17581,7 +17581,7 @@ hcall ( const uint64 H_HOME_NODE_ASSOCIATIVITY), /* Returns in R4-R9 the home no
<para><emphasis role="bold">For the Partition Migration and Partition Hibernation
options:</emphasis> The platform must implement the Partition Suspension
option (See
<xref linkend="LoPAR.RTAS" />).</para>
<xref linkend="dbdoclet.50569332_45918" />).</para>
</listitem>
</varlistentry>

@ -17613,7 +17613,7 @@ hcall ( const uint64 H_HOME_NODE_ASSOCIATIVITY), /* Returns in R4-R9 the home no
<para><emphasis role="bold">For the Partition Migration and Partition Hibernation
options:</emphasis> The platform must implement the Version 6 Extensions
of Event Log Format for all reported events (See
<xref linkend="LoPAR.Error" />).</para>
<xref linkend="dbdoclet.50569337_79682" />).</para>
</listitem>
</varlistentry>

@ -17658,7 +17658,7 @@ hcall ( const uint64 H_HOME_NODE_ASSOCIATIVITY), /* Returns in R4-R9 the home no
<para><emphasis role="bold">For the Partition Migration and Partition Hibernation
options:</emphasis> The platform must present the
<emphasis role="bold"><literal>&#8220;ibm,nominal-tbf&#8221;</literal></emphasis> property (See
<xref linkend="LoPAR.DeviceTree" />) with the value of 512 MHz.</para>
<xref linkend="dbdoclet.50569374_89868" />) with the value of 512 MHz.</para>
</listitem>
</varlistentry>

@ -17668,7 +17668,7 @@ hcall ( const uint64 H_HOME_NODE_ASSOCIATIVITY), /* Returns in R4-R9 the home no
<listitem>
<para><emphasis role="bold">For the Partition Suspension option:</emphasis> The platform
must present the properties from
<xref linkend="LoPAR.DeviceTree" />, as specified by
<xref linkend="dbdoclet.50569374_59715" />, as specified by
<xref linkend="dbdoclet.50569344_83870" />, to a partition.</para>
</listitem>
</varlistentry>
@ -17681,7 +17681,7 @@ hcall ( const uint64 H_HOME_NODE_ASSOCIATIVITY), /* Returns in R4-R9 the home no
value of all properties in
<xref linkend="dbdoclet.50569344_83870" /> must not change while a
partition is suspended except for those properties described by
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569332_40069" />.</para>
</listitem>
</varlistentry>
</variablelist>
@ -18300,7 +18300,7 @@ hcall ( const uint64 H_HOME_NODE_ASSOCIATIVITY), /* Returns in R4-R9 the home no
<listitem>
<para><emphasis role="bold">For the VRMA option:</emphasis> The platform must include the
<emphasis role="bold"><literal>&#8220;ibm,vrma-page-sizes&#8221;</literal></emphasis> property (See
<xref linkend="LoPAR.DeviceTree" />) in the
<xref linkend="dbdoclet.50569374_59715" />) in the
<emphasis role="bold"><literal>/cpu</literal></emphasis> node.</para>
</listitem>
</varlistentry>
@ -18450,7 +18450,7 @@ hcall ( const uint64 H_VRMASD, /* Change the page mapping characteristics of the
(except for time delays) handle all effects of any memory expropriation
that it may introduce unless the CMO option is explicitly enabled by the
setting of architecture.vec option vector 5 byte 4 bit 0 (See
<xref linkend="LoPAR.DeviceTree" /> for details).</para>
<xref linkend="dbdoclet.50569368_10077" /> for details).</para>
<para>The CMO option consists of the following LoPAR extensions:</para>

<itemizedlist>
@ -19977,7 +19977,7 @@ hcall ( const H_GET_MPP_X /* Returns in R4-R10 extended Memory Performance */
Check Interrupt by returning to the partition&#8217;s interrupt vector at
location 0x0200. Note the subsequent firmware assisted NMI and check
exception processing returns a VPM SUE error log (See
<xref linkend="LoPAR.Error" />).</para>
<xref linkend="dbdoclet.50569337_54366" />).</para>
</listitem>
</varlistentry>
</variablelist>
@ -21604,7 +21604,7 @@ hcall ( const uint64 H_REGISTER_PROCESS_TABLE, /* Set translation mode */
the value 1) cede latency specifier settings. Platforms that implement
cede latency specifier settings greater than the value of 1 implement the
cede latency settings system parameter see
<xref linkend="LoPAR.RTAS" />. The hypervisor is then free to take energy
<xref linkend="dbdoclet.50569332_63170" />. The hypervisor is then free to take energy
management actions with this hint in mind.</para>

<variablelist>
@ -21666,7 +21666,7 @@ hcall ( const uint64 H_REGISTER_PROCESS_TABLE, /* Set translation mode */
<para><emphasis role="bold">For the PEM option:</emphasis> If the platform implements cede
latency specifier values greater than 1 it must implement the cede
latency settings system parameter see
<xref linkend="LoPAR.RTAS" />.</para>
<xref linkend="dbdoclet.50569332_63170" />.</para>
</listitem>
</varlistentry>
</variablelist>

@ -1,136 +1,136 @@
<?xml version="1.0"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
xml:id="dbdoclet.50569333_15433"
version="5.0" xml:lang="en">
<title>Non-Volatile Memory</title>

<para>This chapter describes the requirements relating to Non-Volatile
Memory. Non-Volatile Memory is the repository for system information that must
<para>This chapter describes the requirements relating to Non-Volatile
Memory. Non-Volatile Memory is the repository for system information that must
be persistent across reboots and power cycles. </para>

<section xml:id="sec_nvram_sys_req">
<title>System Requirements</title>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_sys_req"
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_sys_req"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>Platforms must implement at least 8 KB of
Non-Volatile Memory. The actual amount is platform dependent and must allow for
4 KB for the OS. Platforms must provide an additional 4 KB for each installed
<para>Platforms must implement at least 8 KB of
Non-Volatile Memory. The actual amount is platform dependent and must allow for
4 KB for the OS. Platforms must provide an additional 4 KB for each installed
OS beyond the first.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_sys_req"
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_sys_req"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>Non-Volatile Memory must maintain its
<para>Non-Volatile Memory must maintain its
contents in the absence of system power.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_sys_req"
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_sys_req"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>Firmware must reinitialize NVRAM to a
<para>Firmware must reinitialize NVRAM to a
bootable state if NVRAM data corruption is detected.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_sys_req"
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_sys_req"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para>OSs must reinitialize their own NVRAM
partitions if NVRAM data corruption is detected. OSs may create free space from
the first corrupted NVRAM partition header to the end of NVRAM and utilize this
<para>OSs must reinitialize their own NVRAM
partitions if NVRAM data corruption is detected. OSs may create free space from
the first corrupted NVRAM partition header to the end of NVRAM and utilize this
area to initialize their NVRAM partitions.</para>
</listitem>
</varlistentry>
</variablelist>

<para><emphasis role="bold">Hardware Implementation Note:</emphasis> The NVRAM terminology used in this
chapter goes back to historic implementations that have used battery-powered
RAM to implement the non-volatile memory. It should be understood that this is
not the only possible implementation. Implementers need to understand that
there are no limits on the frequency of writing to the non-volatile memory, so
certain technologies may not be applicable. Also, it should be noted that the
<emphasis>nvram-fetch</emphasis> and <emphasis>nvram-store</emphasis> RTAS
calls do not allow a &#x201C;busy&#x201D; Status return, and this may further
<para><emphasis role="bold">Hardware Implementation Note:</emphasis> The NVRAM terminology used in this
chapter goes back to historic implementations that have used battery-powered
RAM to implement the non-volatile memory. It should be understood that this is
not the only possible implementation. Implementers need to understand that
there are no limits on the frequency of writing to the non-volatile memory, so
certain technologies may not be applicable. Also, it should be noted that the
<emphasis>nvram-fetch</emphasis> and <emphasis>nvram-store</emphasis> RTAS
calls do not allow a &#x201C;busy&#x201D; Status return, and this may further
limit the implementation choices.</para>
<para><emphasis role="bold">Software Implementation Note:</emphasis> Refer to <xref linkend="LoPAR.RTAS"/>
<para><emphasis role="bold">Software Implementation Note:</emphasis> Refer to <xref linkend="dbdoclet.50569332_26944"/>
for information on accessing NVRAM.</para>
</section>

<section xml:id="sec_nvram_structure">
<title>Structure</title>
<para>NVRAM is formatted as a set of NVRAM partitions that adhere to the
structure in <xref linkend="dbdoclet.50569333_37259"/>. NVRAM partitions are
prefixed with a header containing <emphasis>signature</emphasis>,
<emphasis>checksum</emphasis>, <emphasis>length</emphasis>, and
<emphasis>name</emphasis> fields. The structure of the <emphasis>data</emphasis> field
is defined by the NVRAM partition creator/owner (designated by
<para>NVRAM is formatted as a set of NVRAM partitions that adhere to the
structure in <xref linkend="dbdoclet.50569333_37259"/>. NVRAM partitions are
prefixed with a header containing <emphasis>signature</emphasis>,
<emphasis>checksum</emphasis>, <emphasis>length</emphasis>, and
<emphasis>name</emphasis> fields. The structure of the <emphasis>data</emphasis> field
is defined by the NVRAM partition creator/owner (designated by
<emphasis>signature</emphasis> and <emphasis>name</emphasis>). </para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_structure"
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_structure"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>NVRAM partitions must be structured as shown
<para>NVRAM partitions must be structured as shown
in <xref linkend="dbdoclet.50569333_37259"/>.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_structure"
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_structure"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>All NVRAM space must be accounted for by
<para>All NVRAM space must be accounted for by
NVRAM partitions.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_structure"
<term><emphasis role="bold">R1-<xref linkend="sec_nvram_structure"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>All IBM-defined NVRAM partitions that are
intended to be IBM-unique must have names prefixed with the ASCII
<para>All IBM-defined NVRAM partitions that are
intended to be IBM-unique must have names prefixed with the ASCII
representation of the four characters: <emphasis>ibm,</emphasis>.</para>
</listitem>
</varlistentry>
</variablelist>

<para><emphasis role="bold">Software Implementation Note:</emphasis> Although the data
areas of NVRAM partitions are not required to have error checking, it is
strongly recommended that the system software implement robust data structures
and error checking. Loss of NVRAM structures due to data corruption can be
catastrophic, potentially leading to OS reinstallation and/or complete system
<para><emphasis role="bold">Software Implementation Note:</emphasis> Although the data
areas of NVRAM partitions are not required to have error checking, it is
strongly recommended that the system software implement robust data structures
and error checking. Loss of NVRAM structures due to data corruption can be
catastrophic, potentially leading to OS reinstallation and/or complete system
initialization.</para>
</section>

<section>
<title>Signatures</title>
<para>The <emphasis>signature</emphasis> field is used as the first level
of NVRAM partition identification. <xref linkend="dbdoclet.50569333_24820"/>
lists all the currently defined signature types and their ownership classes.
The ownership class determines the permission of a particular system software
component to create and/or modify NVRAM partitions and/or NVRAM partition
contents. All NVRAM partitions may be read by any system software component,
but the ownership class has exclusive write permission. Global ownership gives
read/write permission to all system software components. These restrictions are
made to minimize the possibility of corruption of NVRAM during update
<para>The <emphasis>signature</emphasis> field is used as the first level
of NVRAM partition identification. <xref linkend="dbdoclet.50569333_24820"/>
lists all the currently defined signature types and their ownership classes.
The ownership class determines the permission of a particular system software
component to create and/or modify NVRAM partitions and/or NVRAM partition
contents. All NVRAM partitions may be read by any system software component,
but the ownership class has exclusive write permission. Global ownership gives
read/write permission to all system software components. These restrictions are
made to minimize the possibility of corruption of NVRAM during update
activities.</para>
<para><emphasis role="bold">Hardware and Software Implementation Note:</emphasis> It is recommended that
NVRAM partitions be ordered on the signature field with the lowest value
signature NVRAM partition at the lowest NVRAM address (with the exception of
signature = 0x7F, free space). This will minimize the effect of NVRAM data
<para><emphasis role="bold">Hardware and Software Implementation Note:</emphasis> It is recommended that
NVRAM partitions be ordered on the signature field with the lowest value
signature NVRAM partition at the lowest NVRAM address (with the exception of
signature = 0x7F, free space). This will minimize the effect of NVRAM data
corruption on system operation.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569333_37259">
@ -167,9 +167,9 @@ version="5.0" xml:lang="en">
<para> 1 byte</para>
</entry>
<entry>
<para> The <emphasis>signature</emphasis> field is used to
identify the NVRAM partition type and provide some level of checking for
overall NVRAM contamination. Signature assignments are given in
<para> The <emphasis>signature</emphasis> field is used to
identify the NVRAM partition type and provide some level of checking for
overall NVRAM contamination. Signature assignments are given in
<xref linkend="dbdoclet.50569333_24820"/>.</para>
</entry>
</row>
@ -181,11 +181,11 @@ version="5.0" xml:lang="en">
<para> 1 byte</para>
</entry>
<entry>
<para> The <emphasis>checksum</emphasis> field is included to
provide a check on the validity of the header. The checksum covers the
<emphasis>signature</emphasis>, <emphasis>length</emphasis>, and
<emphasis>name</emphasis> fields and is calculated (on a byte by byte or equivalent
basis) by: add, and add 1 back to the sum if a carry resulted as demonstrated
<para> The <emphasis>checksum</emphasis> field is included to
provide a check on the validity of the header. The checksum covers the
<emphasis>signature</emphasis>, <emphasis>length</emphasis>, and
<emphasis>name</emphasis> fields and is calculated (on a byte by byte or equivalent
basis) by: add, and add 1 back to the sum if a carry resulted as demonstrated
with the following program listing.<programlisting><![CDATA[unsigned char sumcheck(bp,nbytes)
unsigned char *bp; /* buffer pointer */
unsigned int nbytes; /* number of bytes to sum */
@ -203,7 +203,7 @@ unsigned int nbytes; /* number of bytes to sum */
}
return (c_sum);
}]]></programlisting></para>
<para>This checksum algorithm guarantees 0 to be an impossible
<para>This checksum algorithm guarantees 0 to be an impossible
calculated value. A valid header cannot have a checksum of zero.</para>
</entry>
</row>
@ -215,13 +215,13 @@ unsigned int nbytes; /* number of bytes to sum */
<para> 2 bytes</para>
</entry>
<entry>
<para> The <emphasis>length</emphasis> field designates the
total length of the NVRAM partition, in 16-byte blocks, beginning with the
signature and ending with the last byte of the data area. A length of zero is
<para> The <emphasis>length</emphasis> field designates the
total length of the NVRAM partition, in 16-byte blocks, beginning with the
signature and ending with the last byte of the data area. A length of zero is
invalid.</para>
<para><emphasis role="bold">Software Implementation Note:</emphasis> The
<emphasis>length</emphasis> field must always provide valid offsets to the
next header since an invalid length effectively causes the loss of access to
<para><emphasis role="bold">Software Implementation Note:</emphasis> The
<emphasis>length</emphasis> field must always provide valid offsets to the
next header since an invalid length effectively causes the loss of access to
every NVRAM partition beyond it.</para>
</entry>
</row>
@ -233,18 +233,18 @@ unsigned int nbytes; /* number of bytes to sum */
<para> 12 bytes</para>
</entry>
<entry>
<para> The <emphasis>name</emphasis> field is a 12 byte string
(or a NULL-terminated string of less than 12 bytes) used to identify a
particular NVRAM partition within a signature group. In order to reduce the
likelihood of a naming conflict, each platform-specific or OS-specific NVRAM
partition name should be prefixed with a company name as specified under the
description of the &#x201C;name&#x201D; string in the
<emphasis><xref linkend="dbdoclet.50569387_45524"/>,</emphasis> that is, a company name string
in one of the three forms described in the reference, followed by a comma
(&#x201C;,&#x201D;). If the company name string is null, the name will be
<para> The <emphasis>name</emphasis> field is a 12 byte string
(or a NULL-terminated string of less than 12 bytes) used to identify a
particular NVRAM partition within a signature group. In order to reduce the
likelihood of a naming conflict, each platform-specific or OS-specific NVRAM
partition name should be prefixed with a company name as specified under the
description of the &#x201C;name&#x201D; string in the
<emphasis><xref linkend="dbdoclet.50569387_45524"/>,</emphasis> that is, a company name string
in one of the three forms described in the reference, followed by a comma
(&#x201C;,&#x201D;). If the company name string is null, the name will be
interpreted as &#x201C;other&#x201D;.</para>
<para>Before assigning a new name to a NVRAM partition, software
should scan the existing NVRAM partitions and ensure that an unwanted name
<para>Before assigning a new name to a NVRAM partition, software
should scan the existing NVRAM partitions and ensure that an unwanted name
conflict is not created.</para>
</entry>
</row>
@ -256,7 +256,7 @@ unsigned int nbytes; /* number of bytes to sum */
<para><emphasis>length</emphasis> minus 16 bytes</para>
</entry>
<entry>
<para> The structure of the <emphasis>data</emphasis> area is
<para> The structure of the <emphasis>data</emphasis> area is
controlled by the creator/owner of the NVRAM partition.</para>
</entry>
</row>
@ -350,8 +350,8 @@ unsigned int nbytes; /* number of bytes to sum */
<para> 0 to n</para>
</entry>
<entry>
<para> This signature is used to mark free space in the NVRAM
array. The <emphasis>name</emphasis> field of all signature 0x7F NVRAM
<para> This signature is used to mark free space in the NVRAM
array. The <emphasis>name</emphasis> field of all signature 0x7F NVRAM
partitions must be set to 0x7...77.</para>
</entry>
</row>
@ -374,8 +374,8 @@ unsigned int nbytes; /* number of bytes to sum */
</row>
<row>
<entry nameend="c5" namest="c1" align="left">
<para><emphasis role="bold">Note:</emphasis> Any signature not defined above is reserved, and
signatures 0x02, 0x50, 0x51, 0x52, 0x71, and 0x72 are reserved for legacy
<para><emphasis role="bold">Note:</emphasis> Any signature not defined above is reserved, and
signatures 0x02, 0x50, 0x51, 0x52, 0x71, and 0x72 are reserved for legacy
reasons.</para>
</entry>
</row>
@ -383,136 +383,136 @@ unsigned int nbytes; /* number of bytes to sum */
</tgroup>
</table>
</section>

<section>
<title>Architected NVRAM Partitions</title>

<section xml:id="dbdoclet.50569333_25869">
<title>System (0x70)</title>
<para>System NVRAM partitions are used for storing information
(typically, configuration variables) accessible to both OF and the OS. Refer to
<xref linkend="LoPAR.DeviceTree"/> for the definition of the contents of the
<para>System NVRAM partitions are used for storing information
(typically, configuration variables) accessible to both OF and the OS. Refer to
<xref linkend="dbdoclet.50569368_91814"/> for the definition of the contents of the
System NVRAM partition named <emphasis role="bold"><literal>common</literal></emphasis>.</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_25869"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_25869"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>Every system NVRAM must contain a System
<para>Every system NVRAM must contain a System
NVRAM partition with the NVRAM partition name = <emphasis role="bold"><literal>common</literal></emphasis>.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_25869"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_25869"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>Data in the <emphasis role="bold"><literal>common</literal></emphasis>
NVRAM partition must be stored as NULL-terminated strings of the form:
<emphasis>&lt;name&gt;=&lt;string&gt;</emphasis> and the
<emphasis>data</emphasis> area must be terminated with at least two NULL
<para>Data in the <emphasis role="bold"><literal>common</literal></emphasis>
NVRAM partition must be stored as NULL-terminated strings of the form:
<emphasis>&lt;name&gt;=&lt;string&gt;</emphasis> and the
<emphasis>data</emphasis> area must be terminated with at least two NULL
characters.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_25869"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_25869"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>All <emphasis>names</emphasis> used in
<para>All <emphasis>names</emphasis> used in
the <emphasis role="bold"><literal>common</literal></emphasis> NVRAM partition must be unique.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_25869"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_25869"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para>Device and file specifications used in
the <emphasis role="bold"><literal>common</literal></emphasis> NVRAM partition must follow IEEE Std 1275
<para>Device and file specifications used in
the <emphasis role="bold"><literal>common</literal></emphasis> NVRAM partition must follow IEEE Std 1275
nomenclature conventions.</para>
</listitem>
</varlistentry>
</variablelist>

<section>
<title>System NVRAM Partition</title>
<para>The System NVRAM partition, with name = <emphasis role="bold"><literal>common</literal></emphasis>,
contains information that is accessible to both OF and OSs.
The contents of this NVRAM partition are represented in the OF device tree as
properties (i.e., (<emphasis>name</emphasis>, <emphasis>value</emphasis>)
pairs) in the <emphasis role="bold"><literal>/options</literal></emphasis> node. While OF is available, the
OS can alter the contents of these properties by using the
<emphasis>setprop</emphasis> client interface service. When OF is no longer available,
the OS can alter the contents of the System NVRAM partition itself, following
the rules below for the formats of the <emphasis>name</emphasis> and
<emphasis>value</emphasis>. Information is stored in the System NVRAM
partition as a sequence of (<emphasis>name</emphasis>,
<para>The System NVRAM partition, with name = <emphasis role="bold"><literal>common</literal></emphasis>,
contains information that is accessible to both OF and OSs.
The contents of this NVRAM partition are represented in the OF device tree as
properties (i.e., (<emphasis>name</emphasis>, <emphasis>value</emphasis>)
pairs) in the <emphasis role="bold"><literal>/options</literal></emphasis> node. While OF is available, the
OS can alter the contents of these properties by using the
<emphasis>setprop</emphasis> client interface service. When OF is no longer available,
the OS can alter the contents of the System NVRAM partition itself, following
the rules below for the formats of the <emphasis>name</emphasis> and
<emphasis>value</emphasis>. Information is stored in the System NVRAM
partition as a sequence of (<emphasis>name</emphasis>,
<emphasis>value</emphasis>) pairs in the following format: </para>
<para><emphasis>name = value</emphasis></para>
<para>where <emphasis>name</emphasis> follows the rules defined in
<xref linkend="dbdoclet.50569333_24970"/> and <emphasis>value</emphasis> follows the
rules defined in <xref linkend="dbdoclet.50569333_36194"/>. The end of the
<para>where <emphasis>name</emphasis> follows the rules defined in
<xref linkend="dbdoclet.50569333_24970"/> and <emphasis>value</emphasis> follows the
rules defined in <xref linkend="dbdoclet.50569333_36194"/>. The end of the
sequence of pairs is denoted by a NULL (0x00) byte. </para>

<section xml:id="dbdoclet.50569333_24970">
<title>Name</title>
<para>Since the data in the System NVRAM partition is an external
representation of properties of the <emphasis role="bold"><literal>/option</literal></emphasis> node, the
name component must follow the rules for <emphasis role="bold"><literal>property names</literal></emphasis>
<para>Since the data in the System NVRAM partition is an external
representation of properties of the <emphasis role="bold"><literal>/option</literal></emphasis> node, the
name component must follow the rules for <emphasis role="bold"><literal>property names</literal></emphasis>
as defined by Section 3.2.2.1.1 Property names of
<xref linkend="dbdoclet.50569387_45524"/>; i.e., a string of 1-31 printable
characters containing no uppercase characters or the characters
&#x201C;/&#x201D;, &#x201C;\&#x201D;, &#x201C;:&#x201D;, &#x201C;[&#x201C;,
&#x201C;]&#x201D; or &#x201C;@&#x201D;. In addition to these rules, a naming
convention is required for OS specific names to avoid name conflicts. Each such
name must begin with the OS vendor&#x2019;s OUI followed by a
&#x201C;,&#x201D;; e.g., aapl,<emphasis>xxx</emphasis> or
ibm,<emphasis>xxx</emphasis>. This introduces separate name spaces for each vendor in which
<xref linkend="dbdoclet.50569387_45524"/>; i.e., a string of 1-31 printable
characters containing no uppercase characters or the characters
&#x201C;/&#x201D;, &#x201C;\&#x201D;, &#x201C;:&#x201D;, &#x201C;[&#x201C;,
&#x201C;]&#x201D; or &#x201C;@&#x201D;. In addition to these rules, a naming
convention is required for OS specific names to avoid name conflicts. Each such
name must begin with the OS vendor&#x2019;s OUI followed by a
&#x201C;,&#x201D;; e.g., aapl,<emphasis>xxx</emphasis> or
ibm,<emphasis>xxx</emphasis>. This introduces separate name spaces for each vendor in which
it manages its own naming conventions. </para>
</section>

<section xml:id="dbdoclet.50569333_36194">
<title>Value </title>
<para>The value component of System NVRAM partition data can contain an
arbitrary number of bytes in the range 0x01 to 0xFF, terminated by a NULL
(0x00) byte. Bytes in the range 0x01 to 0xFE represent themselves. In order to
allow arbitrary byte data to be represented, an encoding is used to represent
strings of 0x00 or 0xFF bytes. This encoding uses the 0xFF byte as an escape,
<para>The value component of System NVRAM partition data can contain an
arbitrary number of bytes in the range 0x01 to 0xFF, terminated by a NULL
(0x00) byte. Bytes in the range 0x01 to 0xFE represent themselves. In order to
allow arbitrary byte data to be represented, an encoding is used to represent
strings of 0x00 or 0xFF bytes. This encoding uses the 0xFF byte as an escape,
indicating that the following byte is encoded as:</para>
<para>bnnnnnnn</para>
<para>where b, the most-significant bit, is 0 to represent a sequence of
0x00 bytes or 1 to represent a sequence of 0xFF bytes. nnnnnnn, the
least-significant 7 bits, is a binary number (in the range 0x01 to 0x7F) that
<para>where b, the most-significant bit, is 0 to represent a sequence of
0x00 bytes or 1 to represent a sequence of 0xFF bytes. nnnnnnn, the
least-significant 7 bits, is a binary number (in the range 0x01 to 0x7F) that
represents the number of repetitions of 0x00 or 0xFF. </para>
</section>

<section>
<title>OF Configuration Variables</title>
<para>OF configuration variables control the operation of OF. In addition
to the standard configuration variables defined in
<xref linkend="dbdoclet.50569387_45524"/>, other configuration variables are defined
in <xref linkend="LoPAR.RTAS"/>. While such variables are stored in the System
NVRAM partition as described above, they have additional rules placed on the
format of the value component. Each configuration variable is also represented
by a user interface word (of the same name) that returns stack value(s) when
that word is evaluated. Each also has a platform defined default value; the
absence of a configuration variable in the System NVRAM partition indicates
that the value is set to its default value. The format of the external
representation of configuration variables, and their stack representation, is
defined by Section 7.4.4.1 Configuration Variables of
<xref linkend="dbdoclet.50569387_45524"/>; the format depends upon the data type of
the configuration variable. Whereas the internal storage format is not defined
by <xref linkend="dbdoclet.50569387_45524"/>, this architecture specifies them
as described below. The names of configuration variables are defined in <xref
<para>OF configuration variables control the operation of OF. In addition
to the standard configuration variables defined in
<xref linkend="dbdoclet.50569387_45524"/>, other configuration variables are defined
in <xref linkend="dbdoclet.50569374_59715"/>. While such variables are stored in the System
NVRAM partition as described above, they have additional rules placed on the
format of the value component. Each configuration variable is also represented
by a user interface word (of the same name) that returns stack value(s) when
that word is evaluated. Each also has a platform defined default value; the
absence of a configuration variable in the System NVRAM partition indicates
that the value is set to its default value. The format of the external
representation of configuration variables, and their stack representation, is
defined by Section 7.4.4.1 Configuration Variables of
<xref linkend="dbdoclet.50569387_45524"/>; the format depends upon the data type of
the configuration variable. Whereas the internal storage format is not defined
by <xref linkend="dbdoclet.50569387_45524"/>, this architecture specifies them
as described below. The names of configuration variables are defined in <xref
linkend="dbdoclet.50569387_45524"/>, except as noted otherwise.</para>

<section>
<title>Boolean Configuration Variables </title>
<para>The value of a boolean configuration variable is represented in the
System NVRAM partition as the string &#x201C;true&#x201D; or
&#x201C;false&#x201D;. The following configuration variables are of type
<para>The value of a boolean configuration variable is represented in the
System NVRAM partition as the string &#x201C;true&#x201D; or
&#x201C;false&#x201D;. The following configuration variables are of type
boolean: </para>
<itemizedlist mark="none">
<listitem>
@ -547,9 +547,9 @@ unsigned int nbytes; /* number of bytes to sum */

<section>
<title>Integer Configuration Variables </title>
<para>The value of an integer configuration variable is represented in
the System NVRAM partition as a decimal number or a hexadecimal number preceded
by &#x201C;0x&#x201D;. The following configuration variables are of type
<para>The value of an integer configuration variable is represented in
the System NVRAM partition as a decimal number or a hexadecimal number preceded
by &#x201C;0x&#x201D;. The following configuration variables are of type
integer:</para>
<itemizedlist mark="none">
<listitem>
@ -584,14 +584,14 @@ unsigned int nbytes; /* number of bytes to sum */
</listitem>
</itemizedlist>
</section>

<section>
<title>String Configuration Variables</title>
<para>The value of a string configuration variable is represented in the
System NVRAM partition as the characters of the string. Where multiple
&#x201C;lines&#x201D; of text are represented, each line is terminated by a
carriage-return (0x0D), a line-feed (0x0A), or carriage-return, line-feed
sequence (0x0D, 0x0A). The following configuration variables are of type
<para>The value of a string configuration variable is represented in the
System NVRAM partition as the characters of the string. Where multiple
&#x201C;lines&#x201D; of text are represented, each line is terminated by a
carriage-return (0x0D), a line-feed (0x0A), or carriage-return, line-feed
sequence (0x0D, 0x0A). The following configuration variables are of type
string: </para>
<itemizedlist mark="none">
<listitem>
@ -641,8 +641,8 @@ unsigned int nbytes; /* number of bytes to sum */

<section>
<title>Byte Configuration Variables </title>
<para>The value of a bytes configuration variable is represented by an
arbitrary number of bytes, using the encoding escape for values of 0x00 and
<para>The value of a bytes configuration variable is represented by an
arbitrary number of bytes, using the encoding escape for values of 0x00 and
0xFF. The following configuration variables are of type bytes:</para>
<itemizedlist mark="none">
<listitem>
@ -655,89 +655,89 @@ unsigned int nbytes; /* number of bytes to sum */

<section xml:id="sec_disk_startup">
<title>DASD Spin-up Control</title>
<para> In order to reduce the boot time of platforms, a configuration
variable is defined to communicate from the platform to the OS to what extent
spin-up of hard disk drives can be overlapped. Disk drives generally draw more
current as the motors spin up to operating speed, thus the capacity of the
<para> In order to reduce the boot time of platforms, a configuration
variable is defined to communicate from the platform to the OS to what extent
spin-up of hard disk drives can be overlapped. Disk drives generally draw more
current as the motors spin up to operating speed, thus the capacity of the
power supply limits the ability to spin up drives simultaneously.</para>
<para>The configuration variable
<emphasis role="bold"><literal>ibm,dasd-spin-interval</literal></emphasis> indicates the minimum time, in seconds, that
must be allowed between initiating the spin-up of hard disk drives on the
platform. Presence of this variable potentially allows starting up a drive
prior to receiving completion status from a drive previously started. The
absence of this variable implies no platform knowledge regarding the capability
to overlap and, hence, the OS should wait for the appropriate device status
<para>The configuration variable
<emphasis role="bold"><literal>ibm,dasd-spin-interval</literal></emphasis> indicates the minimum time, in seconds, that
must be allowed between initiating the spin-up of hard disk drives on the
platform. Presence of this variable potentially allows starting up a drive
prior to receiving completion status from a drive previously started. The
absence of this variable implies no platform knowledge regarding the capability
to overlap and, hence, the OS should wait for the appropriate device status
before proceeding to subsequent drives (no overlap).</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_disk_startup"
<term><emphasis role="bold">R1-<xref linkend="sec_disk_startup"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If a platform wants to overlap spinning
up it's hard disk drives to improve boot performance, it must create the
<emphasis role="bold"><literal>ibm,dasd-spin-interval</literal></emphasis> OF configuration variable in the
NVRAM signature 0x70 NVRAM partition named <emphasis role="bold"><literal>common</literal></emphasis> and set
it equal to an integer that represents the minimum time, in seconds, that must
<para>If a platform wants to overlap spinning
up it's hard disk drives to improve boot performance, it must create the
<emphasis role="bold"><literal>ibm,dasd-spin-interval</literal></emphasis> OF configuration variable in the
NVRAM signature 0x70 NVRAM partition named <emphasis role="bold"><literal>common</literal></emphasis> and set
it equal to an integer that represents the minimum time, in seconds, that must
be allowed between initiating the spin-up of drives on the platform.</para>
</listitem>
</varlistentry>
</variablelist>

<para><emphasis role="bold">Firmware Implementation Note:</emphasis> The platform
should provide a user-friendly interface to this variable to allow for the
possibility of a user installing hard disks that do not conform to the original
<para><emphasis role="bold">Firmware Implementation Note:</emphasis> The platform
should provide a user-friendly interface to this variable to allow for the
possibility of a user installing hard disks that do not conform to the original
setting of the variable.</para>
</section>
</section>

<section xml:id="sec_free_space">
<title>Free Space (0x7F)</title>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_free_space"
<term><emphasis role="bold">R1-<xref linkend="sec_free_space"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>All unused NVRAM space must be included
<para>All unused NVRAM space must be included
in a signature = 0x7F Free Space NVRAM partition.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_free_space"
<term><emphasis role="bold">R1-<xref linkend="sec_free_space"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>All Free Space NVRAM partitions must have
<para>All Free Space NVRAM partitions must have
the <emphasis>name</emphasis> field set to 0x7...77.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>

<section xml:id="dbdoclet.50569333_13442">
<title>NVRAM Space Management</title>
<para>The only NVRAM partitions whose size an OS can modify are OS and Free
Space signature NVRAM partitions. As NVRAM partitions are created and modified
by an OS, it is likely that free space will become fragmented; free space
<para>The only NVRAM partitions whose size an OS can modify are OS and Free
Space signature NVRAM partitions. As NVRAM partitions are created and modified
by an OS, it is likely that free space will become fragmented; free space
consolidation may become necessary.</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_13442"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_13442"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>An OS must not move or delete any NVRAM
<para>An OS must not move or delete any NVRAM
partition, except OS and Free Space signature NVRAM partitions. </para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_13442"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569333_13442"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para>The NVRAM partition header checksum must be
<para>The NVRAM partition header checksum must be
calculated as shown in <xref linkend="dbdoclet.50569333_37259"/>.</para>
</listitem>
</varlistentry>

@ -72,7 +72,7 @@ xml:lang="en">
(processor, memory region, and IO slot) conveys information about the resources
statically assigned to the client program; and contains the
<emphasis role="bold"><literal>&#x201C;ibm,associativity&#x201D;</literal></emphasis>
property (see <xref linkend="LoPAR.RTAS"/>). This property allows the client
property (see <xref linkend="dbdoclet.50569368_10192"/>). This property allows the client
program to determine the associativity between any two of it&#x2019;s
resources. The greater the associativity the greater the expected performance
when using those two resources in a given operation.</para>
@ -96,7 +96,7 @@ xml:lang="en">
information for the resources is not provided to prevent erroneous operation.
If the long term mapping changes the client program can be made aware of the
new associativity information using the <emphasis>ibm,update-properties</emphasis> RTAS call (See
<xref linkend="LoPAR.RTAS"/>).</para>
<xref linkend="dbdoclet.50569332_40069"/>).</para>

<variablelist>
<varlistentry xml:id="dbdoclet.50569346_19785">
@ -221,7 +221,7 @@ xml:lang="en">
property byte 5 bit 0 has the value of zero, the
<emphasis role="bold"><literal>&#x201C;ibm,associativity-reference-points&#x201D;</literal></emphasis> property defines
reference points in the <emphasis role="bold"><literal>&#x201C;ibm,associativity&#x201D;</literal></emphasis>
property (see <xref linkend="LoPAR.DeviceTree"/>) which roughly correspond to
property (see <xref linkend="dbdoclet.50569368_41461"/>) which roughly correspond to
traditional notions of platform topology constructs. It is important for the
user to realize that these reference points are not exact and their
characteristics vary among implementations. </para>
@ -281,7 +281,7 @@ xml:lang="en">
<title>Dynamic Reconfiguration with Cross CEC I/O Drawers</title>
<para>Should the configuration change in such a way that the associativity
between an OS image&#x2019;s resources changes, the platform notifies the OS
via an event scan log. See <xref linkend="LoPAR.Error"/>. </para>
via an event scan log. See <xref linkend="dbdoclet.50569337_37595"/>. </para>

<variablelist>
<varlistentry>
@ -307,7 +307,7 @@ xml:lang="en">
and the
<emphasis role="bold"><literal>&#x201C;ibm,current-associativity-domains&#x201D;</literal></emphasis>
properties in the <emphasis role="bold"><literal>/rtas</literal></emphasis> node of the device tree (see
<xref linkend="LoPAR.DeviceTree"/>).</para>
<xref linkend="dbdoclet.50569368_41461"/>).</para>

<variablelist>
<varlistentry>
@ -319,7 +319,7 @@ xml:lang="en">
<emphasis role="bold"><literal>&#x201C;ibm,max-associativity-domains&#x201D;</literal></emphasis>
and the
<emphasis role="bold"><literal>&#x201C;ibm,current-associativity-domains&#x201D;</literal></emphasis>
properties in
properties in
the <emphasis role="bold"><literal>/rtas</literal></emphasis> node of the device tree.</para>
</listitem>
</varlistentry>
@ -343,7 +343,7 @@ xml:lang="en">
preferred.</para>
<para>The OS and platform firmware negotiate their mutual support of the
PRRN option via the <emphasis role="bold"><literal>ibm,client-architecture-support</literal></emphasis>
interface (See <xref linkend="LoPAR.DeviceTree"/>). Should a partition be
interface (See <xref linkend="dbdoclet.50569368_13649"/>). Should a partition be
migrated from a platform that did not support the PRRN option, the target
platform does not notify the partition&#x2019;s OS of any PRRN events and, when
possible avoids changing the affinity among the partition&#x2019;s resources.
@ -353,7 +353,7 @@ xml:lang="en">
events.</para>
<para>A PRRN event is signaled via the RTAS <emphasis>event-scan</emphasis>
mechanism, which returns a Hot Plug Event message &#x201C;fixed
part&#x201D; (See <xref linkend="LoPAR.Error"/>) indicating &#x201C;Platform
part&#x201D; (See <xref linkend="dbdoclet.50569337_28848"/>) indicating &#x201C;Platform
Resource Reassignment&#x201D;. In response to the Hot Plug Event message, the
OS may call <emphasis>ibm,update-nodes</emphasis> to determine which resources
were reassigned, and then <emphasis>ibm,update-properties</emphasis> to obtain
@ -443,7 +443,7 @@ xml:lang="en">
</entry>
<entry align="center">
<para>
<emphasis role="bold">Description, Values (Described in <xref linkend="LoPAR.RTAS"/>)</emphasis>
<emphasis role="bold">Description, Values (Described in <xref linkend="dbdoclet.50569337_75663"/>)</emphasis>
</para>
</entry>
</row>

File diff suppressed because it is too large Load Diff

@ -10,7 +10,7 @@ xml:lang="en">
<title>VPD and Location Code OF Properties</title>
<para>A set of OF properties is defined to facilitate asset protection and
RAS capabilities in LoPAR systems. The following properties are defined in
<xref linkend="LoPAR.DeviceTree"/>):</para>
<xref linkend="dbdoclet.50569368_31220"/>):</para>

<itemizedlist>
<listitem>
@ -137,7 +137,7 @@ xml:lang="en">

<section xml:id="dbdoclet.50569341_23269">
<title>System Identification</title>
<para><xref linkend="LoPAR.DeviceTree"/> provides properties in the
<para><xref linkend="dbdoclet.50569368_91814"/> provides properties in the
&#x201C;OF Root Node&#x201D; section called <emphasis role="bold"><literal>&#x201C;system-id&#x201D;</literal></emphasis>
and<emphasis role="bold"><literal>&#x201C;model&#x201D;</literal></emphasis>.</para>

@ -4707,7 +4707,7 @@ xml:lang="en">
<para> Up to 56</para>
</entry>
<entry>
<para> Processor CoD Capacity Card Info per <xref linkend="LoPAR.RTAS"/></para>
<para> Processor CoD Capacity Card Info per <xref linkend="dbdoclet.50569332_47931"/></para>
</entry>
</row>
<row>
@ -4721,7 +4721,7 @@ xml:lang="en">
<para> Up to 56</para>
</entry>
<entry>
<para> Memory CoD Capacity Card Info per <xref linkend="LoPAR.RTAS"/></para>
<para> Memory CoD Capacity Card Info per <xref linkend="dbdoclet.50569332_47931"/></para>
</entry>
</row>
<row>

@ -431,7 +431,7 @@
<para>Dynamic Reconfiguration (LoPAR indicator type 9002) to indicate
the status of DR operations on a Field Replacable Unit (FRU). More
information on DR indicators can be found in
<xref linkend="LoPAR.Virtualization" />. This indicator is amber
<xref linkend="dbdoclet.50569342_75822" />. This indicator is amber
<footnote xml:id="pgfId-630879">
<para>The term &#8220;amber&#8221; will be used in this chapter to mean
any wavelength between yellow and amber.</para>

@ -1,166 +1,166 @@
<?xml version="1.0"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
xml:id="dbdoclet.50569340_14972"
version="5.0"
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
xml:id="dbdoclet.50569340_14972"
version="5.0"
xml:lang="en">
<title>The Symmetric Multiprocessor Option</title>

<para>This architecture supports the implementation of symmetric
multiprocessor (SMP) systems as an optional feature. This Chapter provides
information concerning the design and programming of such systems. For SMP OF
binding information, see <xref linkend="LoPAR.DeviceTree"/>.</para>
<para>SMP systems differ from uniprocessors in a number of ways. These
differences are not all covered in this chapter. Other chapters that cover
<para>This architecture supports the implementation of symmetric
multiprocessor (SMP) systems as an optional feature. This Chapter provides
information concerning the design and programming of such systems. For SMP OF
binding information, see <xref linkend="dbdoclet.50569368_56107"/>.</para>
<para>SMP systems differ from uniprocessors in a number of ways. These
differences are not all covered in this chapter. Other chapters that cover
SMP-related topics include:</para>

<itemizedlist>
<itemizedlist>
<listitem>
<para>Non-processor-related initialization and other requirements:
<para>Non-processor-related initialization and other requirements:
<xref linkend="dbdoclet.50569327_31987"/></para>
</listitem>

<listitem>
<para>Interrupts: <xref linkend="dbdoclet.50569331_37856"/></para>
</listitem>

<listitem>
<para>Error handling: <xref linkend="LoPAR.Error"/></para>
<para>Error handling: <xref linkend="dbdoclet.50569337_37595"/></para>
</listitem>
</itemizedlist>
</itemizedlist>

<para>Many other general characteristics of SMPs&#x2014;such as
interprocessor communication, load/store ordering, and cache
coherence&#x2014;are defined in <xref linkend="dbdoclet.50569387_99718"/>.
Requirements and recommendations for system organization and time base synchronization are
<para>Many other general characteristics of SMPs&#x2014;such as
interprocessor communication, load/store ordering, and cache
coherence&#x2014;are defined in <xref linkend="dbdoclet.50569387_99718"/>.
Requirements and recommendations for system organization and time base synchronization are
discussed here, along with SMP-specific aspects of the boot process.</para>
<para>SMP platforms require SMP-specific OS support. An OS supporting only
uniprocessor platforms
may not be usable on an SMP, even when an SMP platform has only a single
processor installed; conversely, an SMP-supporting OS may not be usable on a
uniprocessor. It is, however, a requirement that uniprocessor OSs be able to
run on one-processor SMPs, and that SMP-enabled OSs also run on uniprocessors.
<para>SMP platforms require SMP-specific OS support. An OS supporting only
uniprocessor platforms
may not be usable on an SMP, even when an SMP platform has only a single
processor installed; conversely, an SMP-supporting OS may not be usable on a
uniprocessor. It is, however, a requirement that uniprocessor OSs be able to
run on one-processor SMPs, and that SMP-enabled OSs also run on uniprocessors.
See the next section.</para>

<section xml:id="dbdoclet.50569340_29104">
<title>SMP System Organization</title>
<para>This chapter only addresses SMP multiprocessor platforms. This is a
computer system in which multiple processors equally share functional and
timing access to and control over all other system components, including memory
and I/O, as defined in the requirements below. Other
multiprocessor organizations (&#x201C;asymmetric
multiprocessors,&#x201D; &#x201C; attached
processors,&#x201D; etc.) are not included in this architecture. These might,
for example, include systems in which only one processor can perform I/O
operations; or in which processors have private memory that is not accessible
<para>This chapter only addresses SMP multiprocessor platforms. This is a
computer system in which multiple processors equally share functional and
timing access to and control over all other system components, including memory
and I/O, as defined in the requirements below. Other
multiprocessor organizations (&#x201C;asymmetric
multiprocessors,&#x201D; &#x201C; attached
processors,&#x201D; etc.) are not included in this architecture. These might,
for example, include systems in which only one processor can perform I/O
operations; or in which processors have private memory that is not accessible
by other processors. </para>
<para>Requirements <xref linkend="dbdoclet.50569340_73893"/> through
<xref linkend="dbdoclet.50569340_79137"/>, further require that all processors
be of (nearly) equal speed, type, cache characteristics, etc. Requirements for
optional non-uniform multiprocessor platforms are found in
<para>Requirements <xref linkend="dbdoclet.50569340_73893"/> through
<xref linkend="dbdoclet.50569340_79137"/>, further require that all processors
be of (nearly) equal speed, type, cache characteristics, etc. Requirements for
optional non-uniform multiprocessor platforms are found in
<xref linkend="dbdoclet.50569346_35960"/>.</para>

<variablelist>
<varlistentry xml:id="dbdoclet.50569340_80907">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>OSs that do not explicitly support the SMP option must support
<para>OSs that do not explicitly support the SMP option must support
SMP-enabled platforms, actively using only one processor. </para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the Symmetric Multiprocessor
<para><emphasis role="bold">For the Symmetric Multiprocessor
option:</emphasis> SMP OSs must support uniprocessor platforms.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the Symmetric Multiprocessor
option:</emphasis> The extensions defined in
<xref linkend="LoPAR.DeviceTree"/>, and the SMP support section of the RTAS
specifications (see <xref linkend="LoPAR.RTAS"/>) must be implemented.</para>
<para><emphasis role="bold">For the Symmetric Multiprocessor
option:</emphasis> The extensions defined in
<xref linkend="dbdoclet.50569368_56107"/>, and the SMP support section of the RTAS
specifications (see <xref linkend="dbdoclet.50569332_36251"/>) must be implemented.</para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569340_73893">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the Symmetric Multiprocessor or Power Management
option:</emphasis> All processors in the configuration must have equal
functional access and &#x201C;quasi-equal&#x201D;
timing access to all of system memory,
including other processors&#x2019; caches, via cache coherence.
&#x201C;Quasi-equal&#x201D; means that the time required for processors to
access memory is sufficiently close to being equal that all software can ignore
the difference without a noticeable negative impact on system performance; and
<para><emphasis role="bold">For the Symmetric Multiprocessor or Power Management
option:</emphasis> All processors in the configuration must have equal
functional access and &#x201C;quasi-equal&#x201D;
timing access to all of system memory,
including other processors&#x2019; caches, via cache coherence.
&#x201C;Quasi-equal&#x201D; means that the time required for processors to
access memory is sufficiently close to being equal that all software can ignore
the difference without a noticeable negative impact on system performance; and
no software is expected to profitably exploit the difference in timing. </para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569340_25908">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the Symmetric Multiprocessor option:</emphasis>
All processors in the configuration must have equal functional and
&#x201C;quasi-equal&#x201D;
timing access to all I/O devices and IOAs.
&#x201C;Quasi-equal&#x201D; is defined as in Requirement <xref linkend="dbdoclet.50569340_73893"/>,
<para><emphasis role="bold">For the Symmetric Multiprocessor option:</emphasis>
All processors in the configuration must have equal functional and
&#x201C;quasi-equal&#x201D;
timing access to all I/O devices and IOAs.
&#x201C;Quasi-equal&#x201D; is defined as in Requirement <xref linkend="dbdoclet.50569340_73893"/>,
above, with I/O access replacing memory access for this case. </para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569340_63554">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the Symmetric Multiprocessor option:</emphasis>
SMP OSs must at least support SMPs with the same PVR contents and speed. The
<para><emphasis role="bold">For the Symmetric Multiprocessor option:</emphasis>
SMP OSs must at least support SMPs with the same PVR contents and speed. The
PVR contents includes both the PVN and the revision number.</para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569340_79137">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the Symmetric Multiprocessor option:</emphasis>
<para><emphasis role="bold">For the Symmetric Multiprocessor option:</emphasis>
All caches at the same hierarchical level must have the same OF properties.</para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569340_12670">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
<listitem>
<para>Hardware for SMPs must provide a means for synchronizing all the
time bases of all the processors in the platform, for use by platform firmware.
See <xref linkend="LoPAR.RTAS"/>. This is for purposes of clock synchronization
<para>Hardware for SMPs must provide a means for synchronizing all the
time bases of all the processors in the platform, for use by platform firmware.
See <xref linkend="dbdoclet.50569332_36251"/>. This is for purposes of clock synchronization
at initialization and at times when the processor loses time base state.</para>
</listitem>
</varlistentry>

<varlistentry xml:id="dbdoclet.50569340_88608">
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569340_29104"
xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
<listitem>
<para>The platform must initialize and maintain the synchronization of
the time bases and timers of all platform processors such that; for any code
sequence &#x201C;C&#x201D;, run between any two platform processors
&#x201C;A&#x201D; and &#x201C;B&#x201D;, where the reading of the time base or
timer in processor &#x201C;A&#x201D; can be architecturally guaranteed to have
happened later in time than the reading of the time base or timer in processor
&#x201C;B&#x201D;, the value of the time base read by processor
&#x201C;A&#x201D; is greater than or equal to the value of the time base read
<para>The platform must initialize and maintain the synchronization of
the time bases and timers of all platform processors such that; for any code
sequence &#x201C;C&#x201D;, run between any two platform processors
&#x201C;A&#x201D; and &#x201C;B&#x201D;, where the reading of the time base or
timer in processor &#x201C;A&#x201D; can be architecturally guaranteed to have
happened later in time than the reading of the time base or timer in processor
&#x201C;B&#x201D;, the value of the time base read by processor
&#x201C;A&#x201D; is greater than or equal to the value of the time base read
by processor &#x201C;B&#x201D;.</para>
</listitem>
</varlistentry>
@ -168,204 +168,204 @@ xml:lang="en">

<para><emphasis role="bold">Software Implementation Notes:</emphasis></para>

<orderedlist>
<orderedlist>
<listitem>
<para>Requirement <xref linkend="dbdoclet.50569340_80907"/> has
implications on the design of uniprocessor OSs, particularly regarding the
handling of interrupts. See the sections that follow, particularly
<para>Requirement <xref linkend="dbdoclet.50569340_80907"/> has
implications on the design of uniprocessor OSs, particularly regarding the
handling of interrupts. See the sections that follow, particularly
<xref linkend="dbdoclet.50569340_57956"/>.</para>
</listitem>

<listitem>
<para>While Requirement <xref linkend="dbdoclet.50569340_63554"/> does
not require this, OSs are encouraged to support processors of the same type but
different PVR contents as long as their programming models are
<para>While Requirement <xref linkend="dbdoclet.50569340_63554"/> does
not require this, OSs are encouraged to support processors of the same type but
different PVR contents as long as their programming models are
compatible.</para>
</listitem>

<listitem>
<para>Because of performance penalties associated with inter-processor
synchronization, the weakest synchronization primitive that produces correct
operation should be used. For example, <emphasis>eieio</emphasis> can often be
used as part of a sequence that unlocks a data structure, rather than the
<para>Because of performance penalties associated with inter-processor
synchronization, the weakest synchronization primitive that produces correct
operation should be used. For example, <emphasis>eieio</emphasis> can often be
used as part of a sequence that unlocks a data structure, rather than the
higher-overhead but more general <emphasis>sync</emphasis> instruction. </para>
</listitem>
</orderedlist>
</orderedlist>

<para><emphasis role="bold">Hardware Implementation Notes:</emphasis></para>
<orderedlist>
<orderedlist>
<listitem>
<para>Particularly when used as servers, SMP systems make heavy demands
on the I/O and memory subsystems. Therefore, it is strongly recommended that
the I/O and memory subsystem of an SMP platform should either be expandable as
additional processors are added, or else designed to handle the load of the
<para>Particularly when used as servers, SMP systems make heavy demands
on the I/O and memory subsystems. Therefore, it is strongly recommended that
the I/O and memory subsystem of an SMP platform should either be expandable as
additional processors are added, or else designed to handle the load of the
maximum system configuration.</para>
</listitem>

<listitem xml:id="dbdoclet.50569340_marker-513176">
<para>Defining an exact numeric threshold for
&#x201C;quasi-equal&#x201D; is not feasible because it depends on the
application, compiler, subsystem, and OS software that the system is to run. It
is highly likely that a wider range of timing differences can be absorbed in
I/O access time than in memory access time. An illustrative example that is
deliberately far from an upper bound: A 2% timing difference is certainly
quasi-equal by this definition. While significantly larger timing differences
are undoubtedly also quasi-equal, more conclusive statements must be the
<para>Defining an exact numeric threshold for
&#x201C;quasi-equal&#x201D; is not feasible because it depends on the
application, compiler, subsystem, and OS software that the system is to run. It
is highly likely that a wider range of timing differences can be absorbed in
I/O access time than in memory access time. An illustrative example that is
deliberately far from an upper bound: A 2% timing difference is certainly
quasi-equal by this definition. While significantly larger timing differences
are undoubtedly also quasi-equal, more conclusive statements must be the
province of the OS and other software.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>

<section xml:id="dbdoclet.50569340_19429">
<title>An SMP Boot Process</title>
<para>Booting
an SMP entails considerations not present when booting a
uniprocessor. This section indicates those considerations by describing a way
in which an SMP system can be booted. It does not pretend to describe
&#x201C;the&#x201D; way to boot an SMP, since there are a wide variety of ways
to do this, depending on engineering choices that can differ from platform to
platform. To illustrate the possibilities, several variations on the SMP
<para>Booting
an SMP entails considerations not present when booting a
uniprocessor. This section indicates those considerations by describing a way
in which an SMP system can be booted. It does not pretend to describe
&#x201C;the&#x201D; way to boot an SMP, since there are a wide variety of ways
to do this, depending on engineering choices that can differ from platform to
platform. To illustrate the possibilities, several variations on the SMP
booting theme will be described after the initial description.</para>
<para>This section concentrates solely on SMP-related issues, and ignores a
number of other initialization issues such as hibernation and suspension. See
<xref linkend="dbdoclet.50569327_34213"/> for a discussion of those other
<para>This section concentrates solely on SMP-related issues, and ignores a
number of other initialization issues such as hibernation and suspension. See
<xref linkend="dbdoclet.50569327_34213"/> for a discussion of those other
issues. </para>

<section xml:id="dbdoclet.50569340_33673">
<title>SMP-Safe Boot</title>
<para>The basic booting process described here is called
&#x201C;SMP-Safe&#x201D; because it tolerates the presence of multiple
<para>The basic booting process described here is called
&#x201C;SMP-Safe&#x201D; because it tolerates the presence of multiple
processors, but does not exploit them. This process proceeds as follows: </para>

<orderedlist>
<orderedlist>
<listitem>
<para>At power on, one or more finite state machines (FSMs) built into
the system hardware initialize each processor independently. FSMs also perform
basic initialization of other system elements, such as the memory and interrupt
<para>At power on, one or more finite state machines (FSMs) built into
the system hardware initialize each processor independently. FSMs also perform
basic initialization of other system elements, such as the memory and interrupt
controllers. </para>
</listitem>

<listitem>
<para>After the FSM initialization of each processor concludes, it
begins execution at a location in ROM that the FSM has specified. This is the
start of execution of the system firmware that eventually provides the OF
<para>After the FSM initialization of each processor concludes, it
begins execution at a location in ROM that the FSM has specified. This is the
start of execution of the system firmware that eventually provides the OF
interfaces to the OS. </para>
</listitem>

<listitem xml:id="dbdoclet.50569340_44228">
<para>One of the first things that firmware does is establish one of the processors as the
<emphasis>master</emphasis>: The
<emphasis>master</emphasis> is a single processor which
continues with the rest of the booting process; all the others are placed in a
<emphasis>stopped</emphasis> state. A processor in this
<emphasis>stopped</emphasis> state is out of the picture; it does nothing that affects
the state of the system and will continue to be in that state until awakened by
some outside force, such as an inter-processor interrupt (IPI).<footnote xml:id="pgfId-242214"><para>Another
characteristic of the <emphasis>stopped</emphasis> state,
defined in <xref linkend="LoPAR.RTAS"/>, is that the
processor remembers nothing of its prior life when placed in a
<emphasis>stopped</emphasis> state; this distinguishes it from the
<emphasis>idle</emphasis> state. That isn&#x2019;t strictly necessary for this booting
process; <emphasis>idle</emphasis> could have been used. However, since the
non-<emphasis>master</emphasis> processor must be in the
<emphasis>stopped</emphasis> state when the OS is started,
<para>One of the first things that firmware does is establish one of the processors as the
<emphasis>master</emphasis>: The
<emphasis>master</emphasis> is a single processor which
continues with the rest of the booting process; all the others are placed in a
<emphasis>stopped</emphasis> state. A processor in this
<emphasis>stopped</emphasis> state is out of the picture; it does nothing that affects
the state of the system and will continue to be in that state until awakened by
some outside force, such as an inter-processor interrupt (IPI).<footnote xml:id="pgfId-242214"><para>Another
characteristic of the <emphasis>stopped</emphasis> state,
defined in <xref linkend="dbdoclet.50569374_59715"/>, is that the
processor remembers nothing of its prior life when placed in a
<emphasis>stopped</emphasis> state; this distinguishes it from the
<emphasis>idle</emphasis> state. That isn&#x2019;t strictly necessary for this booting
process; <emphasis>idle</emphasis> could have been used. However, since the
non-<emphasis>master</emphasis> processor must be in the
<emphasis>stopped</emphasis> state when the OS is started,
<emphasis>stopped</emphasis> might as well be used.</para></footnote></para>
<para>One way to choose the <emphasis>master</emphasis> is to include a special register
at a fixed address in the memory controller. That special register has the
<para>One way to choose the <emphasis>master</emphasis> is to include a special register
at a fixed address in the memory controller. That special register has the
following properties: </para>

<itemizedlist>
<itemizedlist>
<listitem>
<para>The FSM initializing the memory controller sets this
<para>The FSM initializing the memory controller sets this
register&#x2019;s contents to 0 (zero). </para>
</listitem>

<listitem>
<para>The first time that register is read, it returns the value 0 and
then sets its own contents to non-zero. This is performed as an atomic
operation; if two or more processors attempt to read the register at the same
time, exactly one of them will get the 0 and the rest will get a non-zero
<para>The first time that register is read, it returns the value 0 and
then sets its own contents to non-zero. This is performed as an atomic
operation; if two or more processors attempt to read the register at the same
time, exactly one of them will get the 0 and the rest will get a non-zero
value. </para>
</listitem>

<listitem>
<para>After the first attempt, all attempts to read that
<para>After the first attempt, all attempts to read that
register&#x2019;s contents return a non-zero value. </para>
</listitem>
</itemizedlist>
</itemizedlist>

<para>The <emphasis>master</emphasis> is then picked by having all the
processors read from that special register. Exactly one of them will receive a
<para>The <emphasis>master</emphasis> is then picked by having all the
processors read from that special register. Exactly one of them will receive a
0 and thereby become the <emphasis>master</emphasis>. </para>
<para>Note that the operation of choosing the
<emphasis>master</emphasis> cannot be done using the PA memory locking instructions,
since at this point in the boot process the memory is not initialized. The
advantage to using a register in the memory controller is that system bus
serialization can be used to automatically provide the required
<para>Note that the operation of choosing the
<emphasis>master</emphasis> cannot be done using the PA memory locking instructions,
since at this point in the boot process the memory is not initialized. The
advantage to using a register in the memory controller is that system bus
serialization can be used to automatically provide the required
atomicity.</para>
</listitem>

<listitem>
<para>The <emphasis>master</emphasis> chosen in step
<xref linkend="dbdoclet.50569340_44228"/> then proceeds to do the remainder of the
system initialization. This includes, for example, the remainder of Power-On
Self Test, initialization of OF, discovery of devices and construction of the
OF device tree, loading the OS, starting it, and so on. Since one processor is
performing all these functions, and the rest are in a state where they are not
affecting anything, code that is at least very close to the uniprocessor code
can be used for all of this (but see <xref linkend="dbdoclet.50569340_57956"/>
<para>The <emphasis>master</emphasis> chosen in step
<xref linkend="dbdoclet.50569340_44228"/> then proceeds to do the remainder of the
system initialization. This includes, for example, the remainder of Power-On
Self Test, initialization of OF, discovery of devices and construction of the
OF device tree, loading the OS, starting it, and so on. Since one processor is
performing all these functions, and the rest are in a state where they are not
affecting anything, code that is at least very close to the uniprocessor code
can be used for all of this (but see <xref linkend="dbdoclet.50569340_57956"/>
below).</para>
</listitem>

<listitem>
<para>The OS begins execution on the single
<emphasis>master</emphasis> processor. It uses the OF Client Interface
Services to start each of the other processors, taking them out of the
<para>The OS begins execution on the single
<emphasis>master</emphasis> processor. It uses the OF Client Interface
Services to start each of the other processors, taking them out of the
<emphasis>stopped</emphasis> state and setting them loose on the SMP OS code.</para>
<para>This completes the example SMP boot process. Variations are
discussed beginning at <xref linkend="dbdoclet.50569340_69262"/>. Before
discussing those variations, an element of the system initialization not
<para>This completes the example SMP boot process. Variations are
discussed beginning at <xref linkend="dbdoclet.50569340_69262"/>. Before
discussing those variations, an element of the system initialization not
discussed above will be covered.</para>
</listitem>
</orderedlist>
</orderedlist>

</section>

<section xml:id="dbdoclet.50569340_57956">
<title>Finding the Processor Configuration</title>
<para>Unlike uniprocessor initialization, SMP initialization must also
discover the number and identities of the processors installed in the system.
&#x201C;Identity&#x201D; means the interrupt address of each processor as seen
by the interrupt controller; without that information, a processor cannot reset
interrupts directed at it. This identity is determined by board wiring: The
processor attached to the &#x201C;processor 0&#x201D; wire from the interrupt
controller has identity 0. For information about how this identity is used, see
<xref linkend="LoPAR.DeviceTree"/>.</para>
<para>The method used by a platform to identify its processors is
dependent upon the platform hardware design and may be based upon service
processor information, identification registers, inter-processor interrupts, or
<para>Unlike uniprocessor initialization, SMP initialization must also
discover the number and identities of the processors installed in the system.
&#x201C;Identity&#x201D; means the interrupt address of each processor as seen
by the interrupt controller; without that information, a processor cannot reset
interrupts directed at it. This identity is determined by board wiring: The
processor attached to the &#x201C;processor 0&#x201D; wire from the interrupt
controller has identity 0. For information about how this identity is used, see
<xref linkend="dbdoclet.50569368_56107"/>.</para>
<para>The method used by a platform to identify its processors is
dependent upon the platform hardware design and may be based upon service
processor information, identification registers, inter-processor interrupts, or
other novel techniques.</para>
</section>

<section xml:id="dbdoclet.50569340_69262">
<title>SMP-Efficient Boot </title>
<para>The booting
process as described so far tolerates the existence of multiple processors but
does not attempt to exploit them. It is possible that the booting process can
be sped up by actively using multiple processors simultaneously. In that case,
the pick-a-<emphasis>master</emphasis> technique must still be
used to perform sufficient initialization that other inter-processor
coordination facilities&#x2014;in-memory locks and IPIs&#x2014;can be used.
Once that is accomplished, normal parallel SMP programming techniques can be
<para>The booting
process as described so far tolerates the existence of multiple processors but
does not attempt to exploit them. It is possible that the booting process can
be sped up by actively using multiple processors simultaneously. In that case,
the pick-a-<emphasis>master</emphasis> technique must still be
used to perform sufficient initialization that other inter-processor
coordination facilities&#x2014;in-memory locks and IPIs&#x2014;can be used.
Once that is accomplished, normal parallel SMP programming techniques can be
used within the initialization process itself.</para>
</section>

<section>
<title>Use of a Service Processor</title>
<para>A system might contain a service processor that is distinct from the processors
that form the SMP. If that service processor has suitably intimate access to
and control over each of the SMP processors, it can perform the operations of
choosing a <emphasis>master</emphasis> and discovering the SMP processor
<para>A system might contain a service processor that is distinct from the processors
that form the SMP. If that service processor has suitably intimate access to
and control over each of the SMP processors, it can perform the operations of
choosing a <emphasis>master</emphasis> and discovering the SMP processor
configuration.</para>
<para>&#xA0;</para>
</section>

@ -331,7 +331,7 @@ xml:lang="en">
<section xml:id="dbdoclet.50569327_28943">
<title>Locate an OS Boot Image </title>
<para>The OS boot image is located as described in
<xref linkend="LoPAR.DeviceTree"/>. A device and filename can be specified directly
<xref linkend="dbdoclet.50569368_91814"/>. A device and filename can be specified directly
from the command interpreter (the <emphasis>boot</emphasis> command) or OF
will locate the image through an automatic boot process controlled by
configuration variables. Once a boot image is located, the device path is set
@ -345,7 +345,7 @@ xml:lang="en">
<emphasis role="bold"><literal>boot-device</literal></emphasis> entries that the platform processes.</para>
<para>If multi-boot (multiple bootable OSs residing on the same platform) is supported,
a configuration variable instructs the firmware to display a multi-boot menu
from which the OS and bootpath are selected. See <xref linkend="LoPAR.DeviceTree"/>
from which the OS and bootpath are selected. See <xref linkend="dbdoclet.50569368_91814"/>
for information relating to the multiboot process.</para>

<variablelist>
@ -368,10 +368,10 @@ xml:lang="en">

<section xml:id="dbdoclet.50569327_26247">
<title>Boot Process</title>
<para>The boot process is described in <xref linkend="LoPAR.DeviceTree"/>.
<para>The boot process is described in <xref linkend="dbdoclet.50569368_91814"/>.
Steps in the process are reviewed here, but the
authoritative and complete description of the process is included in
<xref linkend="LoPAR.DeviceTree"/>. <xref linkend="dbdoclet.50569327_17087"/> is a
<xref linkend="dbdoclet.50569368_91814"/>. <xref linkend="dbdoclet.50569327_17087"/> is a
depiction of the boot flow showing the action of the f1, f5, and f6 function
keys. The figure should only be used as an aid in understanding the
requirements for LoPAR systems.</para>
@ -431,7 +431,7 @@ xml:lang="en">
<para>Once the boot prompt is displayed, the System Management Services
(SMS) menu can be invoked. SMS provides a user interface for utilities,
configuration, and the Multiboot Menu (as introduced in
<xref linkend="LoPAR.DeviceTree"/>) for boot/install and the OF command
<xref linkend="dbdoclet.50569368_91814"/>) for boot/install and the OF command
interpreter.</para>
<para>The Multiboot menu is formatted so that block devices that
currently contain boot information are most easily selected by the user.
@ -721,7 +721,7 @@ xml:lang="en">
<emphasis role="bold"><literal>diag-device</literal></emphasis>
configuration variables must include the standard block device
<literal>bootinfo.txt</literal> file specification as documented in
<xref linkend="LoPAR.DeviceTree"/> (<literal>\ppc\bootinfo.txt</literal>).</para>
<xref linkend="dbdoclet.50569368_91814"/> (<literal>\ppc\bootinfo.txt</literal>).</para>
</listitem>
</varlistentry>
</variablelist>
@ -729,7 +729,7 @@ xml:lang="en">

<section xml:id="dbdoclet.50569327_20641">
<title>Tape Boot</title>
<para>Boot from tape is defined in <xref linkend="LoPAR.DeviceTree"/>.</para>
<para>Boot from tape is defined in <xref linkend="dbdoclet.50569368_91814"/>.</para>
</section>

<section xml:id="sec_network_boot">
@ -897,7 +897,7 @@ ELSE
the platform using the <emphasis>ibm,manage-storage-preservation</emphasis>
RTAS call if it wants the contents of the storage preserved across client boot
cycles (see also "Managing Storage Preservations" in
<xref linkend="LoPAR.RTAS"/> specification). The architectural intent of this
<xref linkend="dbdoclet.50569332_28221"/> specification). The architectural intent of this
facility is to enable client programs to emulate persistent storage. This is
done by a client program registering preservable LMBs. Then, after a subsequent
boot cycle (perhaps due to error or impending power loss) the presence of the
@ -1029,7 +1029,7 @@ ELSE
<term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569327_22507"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>Platforms must implement OF as defined in <xref linkend="LoPAR.DeviceTree"/>.</para>
<para>Platforms must implement OF as defined in <xref linkend="dbdoclet.50569368_91814"/>.</para>
</listitem>
</varlistentry>

@ -1053,7 +1053,7 @@ ELSE
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>Platforms must implement the Run-Time Abstraction Services (RTAS) as described in
<xref linkend="LoPAR.RTAS"/>.</para>
<xref linkend="dbdoclet.50569332_13537"/>.</para>
</listitem>
</varlistentry>

@ -1138,7 +1138,7 @@ ELSE
<section>
<title>Tape Install</title>
<para>The OF definition of installation from tape is defined in
<xref linkend="LoPAR.DeviceTree"/>.</para>
<xref linkend="dbdoclet.50569368_91814"/>.</para>
</section>

<section xml:id="sec_network_install">
@ -1167,7 +1167,7 @@ ELSE
will run on other vendors&#x2019; platforms which might not have permission to
use AIX diagnostics, the <emphasis role="bold"><literal>&#x201C;ibm,aix-diagnostics&#x201D;</literal></emphasis>
property indicates that AIX diagnostics are permitted (see "Root
Node Properties" in <xref linkend="LoPAR.DeviceTree"/>).</para>
Node Properties" in <xref linkend="dbdoclet.50569337_42315"/>).</para>

<variablelist>
<varlistentry>
@ -1184,15 +1184,14 @@ ELSE

<para><emphasis role="bold">Software Implementation Note:</emphasis> Each OS may implement an OS-specific
run-time diagnostics package, but should, for purposes of consistency, adhere
to the error log formats in <xref linkend="LoPAR.Error"/>.</para>
to the error log formats in <xref linkend="dbdoclet.50569337_42315"/>.</para>
</section>

<section xml:id="sec_platform_class">
<title>Platform Class</title>
<para>The <emphasis role="bold"><literal>&#x201C;ibm,model-class&#x201D;</literal></emphasis> OF property
is defined to classify platforms for planning, marketing, licensing, and
service purposes (see "Root Node Properties" in
<xref linkend="LoPAR.DeviceTree"/>).</para>
service purposes (see <xref linkend="dbdoclet.50569368_54493"/>).</para>

<variablelist>
<varlistentry>
@ -1696,7 +1695,7 @@ ELSE
<para> OR</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/> for more information. </para>
<para> See <xref linkend="dbdoclet.50569342_75822"/> for more information. </para>
</entry>
</row>
<row>
@ -1710,7 +1709,7 @@ ELSE
<para> OR</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
<para><xref linkend="dbdoclet.50569342_75053"/>.</para>
</entry>
</row>
<row>
@ -1726,8 +1725,8 @@ ELSE
<entry>
<para> See <xref linkend="dbdoclet.50569330_34831"/> and
<xref linkend="dbdoclet.50569330_17337"/>. Requirements for platforms that implement
LPAR, regardless of the number of partitions, are contained in
<xref linkend="LoPAR.Virtualization"/>.</para>
LPAR, regardless of the number of partitions (Requirements <xref linkend="dbdoclet.50569344_47137"/>
and <xref linkend="dbdoclet.50569344_28369"/>).</para>
</entry>
</row>
<row>
@ -1755,7 +1754,7 @@ ELSE
<para> R</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
<para> See <xref linkend="dbdoclet.50569344_14591"/>.</para>
</entry>
</row>
<row>
@ -1801,7 +1800,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.RTAS"/> for more information on
<para> See <xref linkend="dbdoclet.50569332_19739"/> for more information on
support of I<superscript>2</superscript>C buses.</para>
</entry>
</row>
@ -1816,7 +1815,7 @@ ELSE
<para> R</para>
</entry>
<entry>
<para><xref linkend="LoPAR.RTAS"/>. </para>
<para><xref linkend="dbdoclet.50569332_12478"/>. </para>
</entry>
</row>
<row>
@ -1830,7 +1829,7 @@ ELSE
<para> R</para>
</entry>
<entry>
<para><xref linkend="LoPAR.RTAS"/>.</para>
<para><xref linkend="dbdoclet.50569332_24237"/>.</para>
</entry>
</row>
<row>
@ -1844,7 +1843,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.RTAS"/>.</para>
<para><xref linkend="dbdoclet.50569332_41873"/>.</para>
</entry>
</row>
<row>
@ -1858,7 +1857,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.RTAS"/>.</para>
<para><xref linkend="dbdoclet.50569332_61466"/>.</para>
</entry>
</row>
<row>
@ -1888,7 +1887,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
<para><xref linkend="dbdoclet.50569344_27067"/>.</para>
</entry>
</row>
<row>
@ -1902,7 +1901,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
<para><xref linkend="dbdoclet.50569348_48491"/>.</para>
</entry>
</row>
<row>
@ -1916,7 +1915,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
<para><xref linkend="dbdoclet.50569348_61656"/>.</para>
</entry>
</row>
<row>
@ -1930,7 +1929,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
<para><xref linkend="dbdoclet.50569350_23147"/>.</para>
</entry>
</row>
<row>
@ -1944,7 +1943,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
<para><xref linkend="dbdoclet.50569350_17923"/>.</para>
</entry>
</row>
<row>
@ -1958,7 +1957,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
<para><xref linkend="dbdoclet.50569350_53238"/>.</para>
</entry>
</row>
<row>
@ -1972,7 +1971,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
<para> See <xref linkend="dbdoclet.50569350_39278"/>.</para>
</entry>
</row>
<row>
@ -1986,7 +1985,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para><xref linkend="LoPAR.Virtualization"/>.</para>
<para><xref linkend="dbdoclet.50569351_35753"/>.</para>
</entry>
</row>
<row>
@ -2000,7 +1999,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
<para> See <xref linkend="dbdoclet.50569364_64078"/>.</para>
</entry>
</row>
<row>
@ -2014,8 +2013,7 @@ ELSE
<para> NS</para>
</entry>
<entry>
<para><xref linkend="dbdoclet.50569327_70628"/> and "Managing
Storage Preservations" in <xref linkend="LoPAR.RTAS"/> specification.</para>
<para><xref linkend="dbdoclet.50569327_70628"/> and <xref linkend="dbdoclet.50569332_28221"/>.</para>
</entry>
</row>
<row>
@ -2032,7 +2030,7 @@ ELSE
<para> Required of all platforms that support LPAR, otherwise not
implemented. Provides a virtual &#x201C;Asynchronous&#x201D; IOA for connecting
to a server Vterm IOA, the hypervisor, or HMC (for example, to a virtual
console). See <xref linkend="LoPAR.Virtualization"/> for more
console). See <xref linkend="dbdoclet.50569352_15379"/> for more
information.</para>
</entry>
</row>
@ -2068,7 +2066,7 @@ ELSE
</row>
<row>
<entry>
<para> Performance Tool Support</para>
<para>Performance Tool Support</para>
</entry>
<entry>
<para> O</para>
@ -2078,8 +2076,9 @@ ELSE
</entry>
<entry>
<para> Provides access to platform-level facilities for
performance tools running in a partition on an LPAR system. See
<xref linkend="LoPAR.Virtualization"/>.</para>
performance tools running in a partition on an LPAR system.
See
<xref linkend="dbdoclet.50569332_26596"/>.></para>
</entry>
</row>
<row>
@ -2107,7 +2106,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
<para> See <xref linkend="dbdoclet.50569350_39077"/>.</para>
</entry>
</row>
<row>
@ -2121,7 +2120,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
<para> See <xref linkend="sec_vmc"/>.</para>
</entry>
</row>
<row>
@ -2216,7 +2215,7 @@ ELSE
<entry>
<para> Allows an authorized virtual server partition (VSP) to
safely access the internal state of a specific partition. See
<xref linkend="LoPAR.Virtualization"/> for more details. Requires the Reliable
<xref linkend="sec_vasi"/> for more details. Requires the Reliable
Command/Response Transport option.</para>
</entry>
</row>
@ -2248,7 +2247,7 @@ ELSE
<entry>
<para> Allows the OS to indicate that there is no need to search
secondary page table entry groups to determine a page table search has failed.
See <xref linkend="LoPAR.Virtualization"/> for more details.</para>
See <xref linkend="dbdoclet.50569344_39908"/> for more details.</para>
</entry>
</row>
<row>
@ -2292,7 +2291,7 @@ ELSE
</entry>
<entry>
<para> Support for the Subordinate CRQs as needed by some Virtual
IOAs. See <xref linkend="LoPAR.Virtualization"/>.</para>
IOAs. See <xref linkend="dbdoclet.50569348_28179"/>.</para>
</entry>
</row>
<row>
@ -2308,7 +2307,7 @@ ELSE
<entry>
<para> The CMO option allows for partition participation in the
over-commitment of logical memory by the platform. See
<xref linkend="LoPAR.Virtualization"/>.</para>
<xref linkend="dbdoclet.50569344_44716"/>.</para>
</entry>
</row>
<row>
@ -2323,7 +2322,7 @@ ELSE
</entry>
<entry>
<para> Allows the OS to cooperate with platform energy
management. See <xref linkend="LoPAR.Virtualization"/>.</para>
management. See <xref linkend="dbdoclet.50569344_18587"/>.</para>
</entry>
</row>
<row>
@ -2338,7 +2337,7 @@ ELSE
</entry>
<entry>
<para> Support for the Multi-TCE-Table Option. See
<xref linkend="LoPAR.Virtualization"/>.</para>
<xref linkend="dbdoclet.50569344_50921"/>.</para>
</entry>
</row>
<row>
@ -2354,7 +2353,7 @@ ELSE
<entry>
<para> Provides substantially consistent virtual processor
associativity in a shared processor LPAR environment. See
<xref linkend="LoPAR.Virtualization"/>.</para>
<xref linkend="dbdoclet.50569344_56450"/>.</para>
</entry>
</row>
<row>
@ -2382,7 +2381,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
<para> See <xref linkend="dbdoclet.50569366_19541"/>.</para>
</entry>
</row>
<row>
@ -2397,7 +2396,7 @@ ELSE
</entry>
<entry>
<para> Allows OS notification of a cooperative memory
overcommitment page fault see <xref linkend="LoPAR.Virtualization"/>.</para>
overcommitment page fault see <xref linkend="dbdoclet.50569344_20827"/>.</para>
</entry>
</row>
<row>
@ -2413,7 +2412,7 @@ ELSE
<entry>
<para> Allows the platform to communicate and the availability of
performance boost modes along with any ability to manage the same. See
<xref linkend="LoPAR.RTAS"/></para>
<xref linkend="dbdoclet.50569332_57301"/></para>
</entry>
</row>
<row>
@ -2445,7 +2444,7 @@ ELSE
</entry>
<entry>
<para> Allows the creation of DMA Windows above 4 GB. See
<xref linkend="LoPAR.RTAS"/>.</para>
<xref linkend="dbdoclet.50569332_14137"/>.</para>
</entry>
</row>
<row>
@ -2460,7 +2459,7 @@ ELSE
</entry>
<entry>
<para>
<xref linkend="LoPAR.DeviceTree"/> for information on ibm,partition-uuid.
<xref linkend="dbdoclet.50569368_54493"/> for information on ibm,partition-uuid.
</para>
</entry>
</row>
@ -2475,7 +2474,9 @@ ELSE
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/> for more information.</para>
<para> See <xref linkend="dbdoclet.50569344_80550"/>,
<xref linkend="dbdoclet.50569344_61580"/>, and
<xref linkend="dbdoclet.50569344_93738"/> for more information.</para>
</entry>
</row>
<row>
@ -2490,7 +2491,7 @@ ELSE
</entry>
<entry>
<para> Introduces additional cooperative memory overcommitment
functions see <xref linkend="LoPAR.Virtualization"/></para>
functions see <xref linkend="dbdoclet.50569344_44716"/></para>
</entry>
</row>
<row>
@ -2504,7 +2505,7 @@ ELSE
<para> O</para>
</entry>
<entry>
<para> See <xref linkend="LoPAR.Virtualization"/>.</para>
<para> See <xref linkend="sec_mui_opt"/>.</para>
</entry>
</row>
<row>
@ -2563,7 +2564,7 @@ ELSE
</entry>
<entry>
<para>Allows partitions to resize their HPT. See
<xref linkend="LoPAR.Virtualization"/>.</para>
<xref linkend="sec_hash_page_table_resize_option"/>.</para>
</entry>
</row>
<row>
@ -2577,8 +2578,8 @@ ELSE
<para>O</para>
</entry>
<entry>
<para>Allows partitions to resize their HPT. See
<xref linkend="LoPAR.Virtualization"/>.</para>
<para>See
<xref linkend="sec_coherent_platform_facilities"/>.</para>
</entry>
</row>
</tbody>

@ -193,7 +193,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
access modes, like writing to a read only page). More
information on TCEs and TCE tables, which are used for physical
IOAs, can be found in
<xref linkend="LoPAR.Platform" />. The RTCE table for Remote
<xref linkend="dbdoclet.50569328_76588" />. The RTCE table for Remote
DMA (RDMA) is analogous to the TCE table for physical IOAs. The
RTCE table does, however, have a little more information in it
(as placed there by the hypervisor) in order to, among other
@ -728,7 +728,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
</entry>
<entry>
<para>The virtual location code (see
<xref linkend="LoPAR.Platform" />)</para>
<xref linkend="dbdoclet.50569341_32742" />)</para>
</entry>
</row>
<row>
@ -953,7 +953,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
assignment number is uniquely generated when the virtual IOA is assigned
to the partition and remains invariably associated with that virtual IOA
for the duration of the partition definition. For more information, see
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</section>

<section xml:id="dbdoclet.50569348_27549">
@ -1153,7 +1153,7 @@ hcall ( const int64 H_VIO_SIGNAL, /* Function Code */
<emphasis role="bold"><literal>root</literal></emphasis> node, a node of type
<emphasis role="bold"><literal>vdevice</literal></emphasis> as the parent of a sub-tree representing the
virtual IOAs assigned to the partition (see
<xref linkend="LoPAR.DeviceTree" /> for details).</para>
<xref linkend="dbdoclet.50569368_91814" /> for details).</para>
</listitem>
</varlistentry>

@ -1252,7 +1252,7 @@ hcall ( const int64 H_VIO_SIGNAL, /* Function Code */
<listitem>
<para><emphasis role="bold">For all VIO options:</emphasis> The platform must assign an
invariant virtual location code to each virtual IOA as described in
<xref linkend="LoPAR.Platform" />.
<xref linkend="dbdoclet.50569341_32742" />.
</para>
</listitem>
</varlistentry>
@ -3326,7 +3326,7 @@ hcall ( const unit64 H_VIOCTL, /* Query/Set behaviors for the virtual IOA */
<para>Transfer into registers R4 (High order 8 bytes) and R5 (low order
8 bytes) of the UUID of the client partition that owns the virtual device
(
<xref linkend="LoPAR.DeviceTree" /> for the format of the UUID string.</para>
<xref linkend="dbdoclet.50569332_20419" /> for the format of the UUID string.</para>
</listitem>

<listitem>
@ -8852,7 +8852,7 @@ hcall ( const int64 H_SEND_SUB_CRQ, /* Function Code */
<para>Property name specifying the unique and persistent
location code associated with this virtual IOA, the value shall
be of the form defined in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -9108,7 +9108,7 @@ hcall ( const int64 H_SEND_SUB_CRQ, /* Function Code */
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-size-cells&#8221;</literal></emphasis> property
in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -9128,7 +9128,7 @@ hcall ( const int64 H_SEND_SUB_CRQ, /* Function Code */
format cannot be derived using the method described in the
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-address-cells&#8221;</literal></emphasis> property in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
</tbody>
@ -12455,7 +12455,7 @@ hcall ( const uint64 H_ILLAN_ATTRIBUTES,/* Returns in R4 the resulting ILLAN */
encoded array as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>. The value shall be of the
form specified in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -12552,7 +12552,7 @@ hcall ( const uint64 H_ILLAN_ATTRIBUTES,/* Returns in R4 the resulting ILLAN */
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-size-cells&#8221;</literal></emphasis> property
in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -12572,7 +12572,7 @@ hcall ( const uint64 H_ILLAN_ATTRIBUTES,/* Returns in R4 the resulting ILLAN */
format cannot be derived using the method described in the
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-address-cells&#8221;</literal></emphasis> property in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
</tbody>
@ -12750,7 +12750,7 @@ hcall ( const uint64 H_ILLAN_ATTRIBUTES,/* Returns in R4 the resulting ILLAN */
encoded array as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>. The value shall be of the
form
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -12872,7 +12872,7 @@ hcall ( const uint64 H_ILLAN_ATTRIBUTES,/* Returns in R4 the resulting ILLAN */
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-size-cells&#8221;</literal></emphasis> property
in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -12892,7 +12892,7 @@ hcall ( const uint64 H_ILLAN_ATTRIBUTES,/* Returns in R4 the resulting ILLAN */
format cannot be derived using the method described in the
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-address-cells&#8221;</literal></emphasis> property in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
</tbody>
@ -13467,7 +13467,7 @@ hcall ( const uint64 H_ILLAN_ATTRIBUTES,/* Returns in R4 the resulting ILLAN */
encoded array as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>. The value shall be of the
form specified in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -13720,7 +13720,7 @@ hcall ( const uint64 H_ILLAN_ATTRIBUTES,/* Returns in R4 the resulting ILLAN */
encoded array as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>. The value shall be of the
form
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -15231,8 +15231,7 @@ hcall ( const uint64 H_FREE_VTERM, /* Break connection between server and partne
presented as an encoded array as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>.
The value shall be of the form specified in
<xref linkend="LoPAR.Platform" /> information on
Virtual Card Connector Location Codes.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -15317,7 +15316,7 @@ hcall ( const uint64 H_FREE_VTERM, /* Break connection between server and partne
the method described in the definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-size-cells&#8221;</literal></emphasis>
property in
<xref linkend="LoPAR.DeviceTree" /> section on System Bindings.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -15336,7 +15335,7 @@ hcall ( const uint64 H_FREE_VTERM, /* Break connection between server and partne
the method described in the definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-address-cells&#8221;</literal></emphasis>
property in
<xref linkend="LoPAR.DeviceTree" /> section on System Bindings.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
</tbody>
@ -15542,8 +15541,7 @@ hcall ( const uint64 H_FREE_VTERM, /* Break connection between server and partne
presented as an encoded array as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>.
The value shall be of the form specified in
<xref linkend="LoPAR.Platform" /> information on
Virtual Card Connector Location Codes.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -15633,7 +15631,7 @@ hcall ( const uint64 H_FREE_VTERM, /* Break connection between server and partne
the method described in the definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-size-cells&#8221;</literal></emphasis>
property in
<xref linkend="LoPAR.DeviceTree" /> section on System Bindings.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -15652,7 +15650,7 @@ hcall ( const uint64 H_FREE_VTERM, /* Break connection between server and partne
the method described in the definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-address-cells&#8221;</literal></emphasis>
property in
<xref linkend="LoPAR.DeviceTree" /> section on System Bindings.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
</tbody>
@ -18503,8 +18501,7 @@ able 252 “VASI Reliable CRQ Response Status Values” on page 721.
presented as an encoded array as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>.
The value shall be of the form specified in
<xref linkend="LoPAR.Platform" /> information on
Virtual Card Connector Location Codes.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -20749,7 +20746,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
encoded array as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>. The value shall be of the
form specified in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -20846,7 +20843,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-size-cells&#8221;</literal></emphasis> property
in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -20866,7 +20863,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
format cannot be derived using the method described in the
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-address-cells&#8221;</literal></emphasis> property in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -21101,7 +21098,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
encoded array as with
<emphasis role="bold"><literal>encode-string</literal></emphasis>. The value shall be of the
form
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569341_32742" />.</para>
</entry>
</row>
<row>
@ -21223,7 +21220,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-size-cells&#8221;</literal></emphasis> property
in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -21243,7 +21240,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
format cannot be derived using the method described in the
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-address-cells&#8221;</literal></emphasis> property in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -21717,7 +21714,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-size-cells&#8221;</literal></emphasis> property
in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -21740,7 +21737,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
format cannot be derived using the method described in the
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-address-cells&#8221;</literal></emphasis> property in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -22208,7 +22205,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
using the method described in the definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-address-cells&#8221;</literal></emphasis> property
in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -22229,7 +22226,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
definition for the
<emphasis role="bold"><literal>&#8220;ibm,#dma-size-cells&#8221;</literal></emphasis> property
in
<xref linkend="LoPAR.DeviceTree" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</entry>
</row>
<row>
@ -22270,7 +22267,7 @@ hcall ( const uint64 H_VASI_STATE, /* Return the state of the VASI service */
</entry>
<entry>
<para>Vendor unique property name indicating ranges of the client program virtual address space that are used by the virtual device serving partition adjunct.
See <xref linkend="LoPAR.DeviceTree" /> information about the children
See <xref linkend="dbdoclet.50569368_26956" /> information about the children
of the <literal>/vdevice</literal> node.</para>
</entry>
</row>

@ -33,7 +33,7 @@
to hold OF options, RTAS information, machine configuration state, OS
state, diagnostic logs, etc. The type and size of NVRAM is specified in
the OF device tree. The format of NVRAM is detailed in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569333_15433" />.</para>
<para>In order to give the OS the ability to access
NVRAM on
different platforms that may use different implementations or locations
@ -346,7 +346,7 @@
<para>The caller of the
<emphasis>nvram-store</emphasis> RTAS call must maintain the NVRAM
partitions as specified in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569333_15433" />.</para>
</listitem>
</varlistentry>
</variablelist>
@ -362,7 +362,7 @@
clock which maintains the time of day even if power to the machine is
removed. Minimum requirements for this clock are described in Requirement

<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569327_71913" />.</para>

<section xml:id="sec_TOD">
<title>Time of Day Inputs/Outputs</title>
@ -785,7 +785,7 @@
<para><emphasis role="bold">Software Implementation Note:</emphasis> The OS maintains the clock in UTC.
This allows the OS and diagnostics to co-exist with each other and
provide uniform handling of time. Refer to Requirement
<xref linkend="LoPAR.Platform" /> for further details on the time
<xref linkend="dbdoclet.50569327_71913" /> for further details on the time
of day clock.</para>
</listitem>
</varlistentry>
@ -1232,7 +1232,7 @@
<listitem>
<para>The <emphasis>event-scan</emphasis> call must fill in the error log with a
single error log formatted as specified in
<xref linkend="LoPAR.Error" />. If necessary, the data placed
<xref linkend="dbdoclet.50569337_22801" />. If necessary, the data placed
into the error log must be truncated to
<emphasis>length</emphasis> bytes.</para>
</listitem>
@ -1246,7 +1246,7 @@
that are within the classes defined by the
<emphasis>Event mask. Event mask</emphasis> is a bit mask of error and
event classes. Refer to
<xref linkend="LoPAR.Error" /> for the definition of the bit
<xref linkend="dbdoclet.50569337_82470" /> for the definition of the bit
positions.</para>
</listitem>
</varlistentry>
@ -1602,7 +1602,7 @@
<listitem>
<para>The <emphasis>check-exception</emphasis> call must fill in the error log with
a single error log formatted as specified in
<xref linkend="LoPAR.Error" />. The data in the error log
<xref linkend="dbdoclet.50569337_22801" />. The data in the error log
must be truncated to
<emphasis>length</emphasis> bytes.</para>
</listitem>
@ -1636,7 +1636,7 @@
that are within the classes defined by the
<emphasis>Event mask. Event mask</emphasis> is a bit mask of error and
event classes. Refer to
<xref linkend="LoPAR.Error" /> for the definition of the bit
<xref linkend="dbdoclet.50569337_82470" /> for the definition of the bit
positions.</para>
</listitem>
</varlistentry>
@ -1655,7 +1655,7 @@
<para>The
<emphasis>interrupt number</emphasis> for external device interrupts is
provided in the OF device tree as specified in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569368_91814" />.</para>
</listitem>

<listitem>
@ -1789,7 +1789,7 @@
<listitem>
<para>The <emphasis>rtas-last-error</emphasis> call must fill in the error log with
a single error log formatted as specified in
<xref linkend="LoPAR.Error" />. If necessary, the data placed
<xref linkend="dbdoclet.50569337_22801" />. If necessary, the data placed
into the error log must be truncated to &#8216;length&#8221;
bytes.</para>
</listitem>
@ -2689,7 +2689,7 @@
<para>Device drivers and system software need access to
PCI
configuration space.
<xref linkend="LoPAR.Platform" /> section on "Address Map" defines
<xref linkend="dbdoclet.50569328_Address-Map" /> defines
system address spaces for PCI memory and PCI I/O spaces. It does not
define an address space for PCI configuration. Different PCI bridges may
implement the mechanisms for accessing PCI configuration space in
@ -2842,7 +2842,7 @@
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para>RTAS must follow the rules of
<xref linkend="LoPAR.Platform" /> when accessing PCI
<xref linkend="dbdoclet.50569330_49381" /> when accessing PCI
configuration space.</para>
</listitem>
</varlistentry>
@ -2866,7 +2866,7 @@
PCI-X Mode 2 and PCI Express devices, an IOA device driver is responsible
for checking if the
<emphasis role="bold"><literal>&#8220;ibm,pci-config-space-type&#8221;</literal></emphasis> property (see
<xref linkend="LoPAR.DeviceTree" />) of the IOA's node exists and
<xref linkend="dbdoclet.50569368_43390" />) of the IOA's node exists and
is set to a non-zero value.</para>
</listitem>
</orderedlist>
@ -3677,7 +3677,7 @@
control characters carriage-return (CR) (0x0D) and line-feed (LF)
(0x0A).</para>
<para>The following OF properties are defined in
<xref linkend="LoPAR.DeviceTree" />:</para>
<xref linkend="dbdoclet.50569368_41461" />:</para>

<itemizedlist>
<listitem>
@ -4993,7 +4993,7 @@
</entry>
<entry>
<para>When tone is required. See Requirement
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569327_91037" />.</para>
</entry>
<entry>
<para>ibm</para>
@ -5023,7 +5023,7 @@
</entry>
<entry>
<para>When tone is required. See Requirement
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569327_91037" />.</para>
</entry>
<entry>
<para>ibm</para>
@ -5170,7 +5170,7 @@
<para>Isolate refers to the DR action to logically disconnect
from the platform and/or OS (for example, for PCI, isolate from
the bus and from the OS). See
<xref linkend="LoPAR.Virtualization" /> for more
<xref linkend="dbdoclet.50569342_61130" /> for more
details.</para>
</entry>
</row>
@ -5206,8 +5206,8 @@
or just an Identify/Action indicator. Identify and Action may
map to the same visual state (for example, the same blink
rate). See
<xref linkend="LoPAR.Error" /> and
<xref linkend="LoPAR.Virtualization" /> for more
<xref linkend="dbdoclet.50569347_31867" /> and
<xref linkend="dbdoclet.50569342_42695" /> for more
information.</para>
</entry>
</row>
@ -5240,7 +5240,7 @@
<para>Allows an OS image to assign (usable, exchange, or
recover) resources from the firmware or, release resources from
the OS to the firmware. See
<xref linkend="LoPAR.Virtualization" /> for more
<xref linkend="dbdoclet.50569342_61130" /> for more
details.</para>
</entry>
</row>
@ -5321,7 +5321,7 @@
<entry>
<para>Yes</para>
<para>See
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</entry>
<entry>
<para>ibm</para>
@ -5335,8 +5335,8 @@
system or a partition requires operator intervention for
another reason. The Error Log indicator is located only on the
Primary Enclosure. See
<xref linkend="LoPAR.Error" /> and
<xref linkend="LoPAR.Virtualization" /> for more
<xref linkend="dbdoclet.50569347_31867" /> and
<xref linkend="dbdoclet.50569342_42695" /> for more
information.</para>
</entry>
</row>
@ -5360,7 +5360,7 @@
<entry>
<para>Yes</para>
<para>See
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</entry>
<entry>
<para>ibm</para>
@ -5377,8 +5377,8 @@
protect against the use of multiple 9007 indicators
simultaneously or multiple uses of the same 9007 indicator
simultaneously. See
<xref linkend="LoPAR.Error" /> and
<xref linkend="LoPAR.Virtualization" /> for more
<xref linkend="dbdoclet.50569347_31867" /> and
<xref linkend="dbdoclet.50569342_42695" /> for more
information.</para>
</entry>
</row>
@ -5696,8 +5696,7 @@
<para>-1: Hardware Error</para>
<para>-2: Hardware Busy, Try again later</para>
<para>-3: No such sensor implemented</para>
<para>-9000: DR Entity isolated (
<xref linkend="LoPAR.Virtualization" />)</para>
<para>-9000: DR Entity isolated (<xref linkend="dbdoclet.50569342_75822" />)</para>
</entry>
</row>
<row>
@ -5774,7 +5773,7 @@
<listitem>
<para>Critical High - The sensor value is greater than or equal to this
limit. The platform may take some action and may initiate an EPOW (see
<xref linkend="LoPAR.Error" />). The OS may take some action
<xref linkend="dbdoclet.50569337_17513" />). The OS may take some action
to correct this situation or to perform an orderly shutdown.</para>
</listitem>

@ -6260,8 +6259,8 @@
<para>Used in Dynamic Reconfiguration operations to determine
if connector is available and whether the user performed a
particular DR operation correctly. See
<xref linkend="LoPAR.Virtualization" /> and
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569342_75822" /> and
<xref linkend="dbdoclet.50569342_85040" />.</para>
</entry>
</row>
<row>
@ -6331,7 +6330,7 @@
<entry>
<para>Yes</para>
<para>See
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</entry>
<entry>
<para>ibm</para>
@ -6359,7 +6358,7 @@
<entry>
<para>Yes</para>
<para>See
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569347_31867" />.</para>
</entry>
<entry>
<para>ibm</para>
@ -6743,7 +6742,7 @@
sensor. For example, the first entry of
<emphasis role="bold"><literal>&#8220;ibm,sensor-9001&#8221;</literal></emphasis> contains the location
code for fan#1. Location codes are shown in
<xref linkend="LoPAR.Platform" />. Of course, since it is an
<xref linkend="dbdoclet.50569341_35066" />. Of course, since it is an
abstracted sensor, the entry for
<emphasis role="bold"><literal>&#8220;ibm,sensor-9000&#8221;</literal></emphasis> is NULL.</para>
</section>
@ -6853,7 +6852,7 @@
property
<emphasis role="bold"><literal>&#8220;ibm,environmental-sensors&#8221;</literal></emphasis> in the
<emphasis role="bold"><literal>/rtas</literal></emphasis> node (see
<xref linkend="LoPAR.DeviceTree" />).</para>
<xref linkend="dbdoclet.50569368_41461" />).</para>
</listitem>
</varlistentry>
</variablelist>
@ -7749,7 +7748,7 @@
under a UPS would be given by the platform as an EPOW event with EPOW
event modifier being given as, 0x02 = Loss of utility power, system is
running on UPS/Battery, as described in section
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569337_81250" />.</para>
</listitem>

<listitem>
@ -7786,7 +7785,7 @@
<emphasis>system-reboot</emphasis> call which resets all processors and
all attached devices. After reset, the system must be booted with the
current settings of the System Environment Variables (refer to
<xref linkend="LoPAR.Platform" /> for more information).</para>
<xref linkend="dbdoclet.50569333_25869" /> for more information).</para>
</listitem>
</varlistentry>

@ -7894,7 +7893,7 @@
in this section. It does not return to the OS if successful. This call
supports RTAS instantiated in 32 bit mode to access storage at addresses
above 4GB. In an exception to the LPAR Requirement
<xref linkend="LoPAR.Virtualization" /> this call supports block lists
<xref linkend="dbdoclet.50569344_48079" /> this call supports block lists
being outside of the Real Mode Area (RMA) as long as the initial block
list is at an address below the limits of the cell size of the
<emphasis>Block_list</emphasis> argument.</para>
@ -8213,7 +8212,7 @@
<title>Flash Update with Discontiguous Block Lists</title>
<para>The property
<emphasis role="bold"><literal>&#8220;ibm,flash-block-version&#8221;</literal></emphasis> (see
<xref linkend="LoPAR.DeviceTree" />) is defined to describe the
<xref linkend="dbdoclet.50569368_41461" />) is defined to describe the
following definition and operation of the
<emphasis>Block_list</emphasis> shown in
<xref linkend="dbdoclet.50569332_71043" />.</para>
@ -9014,7 +9013,7 @@
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis>(Merged into Requirement
<xref linkend="LoPAR.Platform" />)</emphasis></para>
<xref linkend="dbdoclet.50569340_88608" />)</emphasis></para>
</listitem>
</varlistentry>

@ -9023,7 +9022,7 @@
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis>(Merged into Requirement
<xref linkend="LoPAR.Platform" />)</emphasis></para>
<xref linkend="dbdoclet.50569340_88608" />)</emphasis></para>
</listitem>
</varlistentry>
</variablelist>
@ -9363,7 +9362,7 @@

<para>
<emphasis role="bold">Note:</emphasis> Requirement
<xref linkend="LoPAR.Platform" /> applies to the start-cpu RTAS
<xref linkend="dbdoclet.50569329_35915" /> applies to the start-cpu RTAS
call. At the completion of start-cpu, the caches to be used by the
specified processor must have been initialized and the state bits made
accurate prior to beginning execution at the start address.</para>
@ -10593,7 +10592,7 @@
favored level by firmware at boot), of the External Interrupt Vector
Entry associated with the interrupt number provided as an input argument
unless prevented by Requirement
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569344_75733" />.</para>
</listitem>
</varlistentry>

@ -10789,7 +10788,7 @@
<emphasis>ibm,int-on</emphasis> call since boot), associated with the
interrupt number provided as an input argument unless prevented by
Requirement
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569344_35543" />.</para>
</listitem>
</varlistentry>

@ -10978,7 +10977,7 @@
<emphasis>ibm,int-off</emphasis> call must disable interrupts from the
interrupt source associated with the interrupt number provided as an
input argument unless prevented by Requirement
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569344_77100" />.</para>
</listitem>
</varlistentry>

@ -10997,7 +10996,7 @@
<emphasis>ibm,get-xive</emphasis> call and set the priority value of the
XIVE to the least favored priority value (0xFF), unless prevented by
Requirement
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569344_77100" />.</para>
</listitem>
</varlistentry>

@ -11150,7 +11149,7 @@
<emphasis>ibm,int-on</emphasis> call must enable interrupts from the
interrupt source associated with the interrupt number provided as an
input argument unless prevented by Requirement
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569344_77846" />.</para>
</listitem>
</varlistentry>

@ -11167,7 +11166,7 @@
saved by the previous
<emphasis>ibm,int-off</emphasis> call (initialized by the firmware to the
least favored level at boot) unless prevented by Requirement
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569344_77100" />.</para>
</listitem>
</varlistentry>

@ -11280,7 +11279,7 @@
<title>MSI Support</title>
<para>This section describes the RTAS calls required when the MSI option
is implemented. See
<xref linkend="LoPAR.Platform" /> for other platform requirements
<xref linkend="dbdoclet.50569331_33067" /> for other platform requirements
for the MSI option.</para>
<para>The Message Signaled Interrupt (MSI) and Enhanced MSI (MSI-X)
capability of PCI IOAs in many cases allows for greater flexibility in
@ -11371,7 +11370,7 @@
interrupts from the IOA function. It is permissible to use LSI, MSI and
MSI-X on different IOA functions.</para>
<para>The default (initial) assignment of interrupts is defined in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569331_33067" />.</para>

<variablelist>
<varlistentry>
@ -11818,7 +11817,7 @@

<listitem>
<para>MSIs and MSI source numbers are not shared (see Requirement
<xref linkend="LoPAR.Platform" />).</para>
<xref linkend="dbdoclet.50569331_84312" />).</para>
</listitem>

<listitem>
@ -11859,8 +11858,7 @@
<listitem>
<para>The platform will return a status -2 or 990x only when the OS
indicates support. The OS indicates support via ibm,client-architecture-support,
vector 4. See <xref linkend="LoPAR.DeviceTree" /> section on "Root Node Methods"
for more information.</para>
vector 4. See <xref linkend="dbdoclet.50569368_13649" />.</para>
</listitem>
</orderedlist>

@ -12121,7 +12119,7 @@
order to be able to test device driver code that implements recovery
based on the EEH option.</para>
<para>See also,
<xref linkend="LoPAR.Platform" />, for additional information
<xref linkend="dbdoclet.50569381_46906" />, for additional information
about implementing EEH error recovery.</para>

<variablelist>
@ -13212,15 +13210,14 @@
</tgroup>
</table>

<para>The PE configuration address (
<emphasis>PHB_Unit_ID_Hi, PHB_Unit_ID_Low, and config_addr</emphasis>)
<para>The PE configuration address (<emphasis>PHB_Unit_ID_Hi, PHB_Unit_ID_Low, and config_addr</emphasis>)
for the domain is the PCI configuration address for the PE primary bus
and is the same format as used for the ibm,read-pci-config and
ibm,write-pci-config calls (see Requirement
<xref linkend="dbdoclet.50569332_13648" />), except that the Register
field is set to 0. The PE configuration address is obtained as indicated
in
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569330_40070" />.</para>

<section xml:id="dbdoclet.50569332_27269">
<title><emphasis>ibm,set-eeh-option</emphasis></title>
@ -13386,7 +13383,7 @@
<emphasis>ibm,set-eeh-option Function</emphasis> 1 (enable EEH) is still
required as a signalling method from the device driver to the platform
that the device driver is at least EEH aware (see Requirement
<xref linkend="LoPAR.Platform" />).</para>
<xref linkend="dbdoclet.50569330_49770" />).</para>
</listitem>
</varlistentry>

@ -13910,7 +13907,7 @@
that call can be used instead of this one to determine the PE
configuration address. See
<xref linkend="dbdoclet.50569332_68098" /> and
<xref linkend="LoPAR.Platform" />.</para>
<xref linkend="dbdoclet.50569330_40070" />.</para>

<variablelist>
<varlistentry>
@ -13986,7 +13983,7 @@
&#8220;ibm,read-slot-reset-state-functions&#8221;</literal></emphasis> property
in the
<emphasis>RTAS</emphasis> node of the device tree (
<xref linkend="LoPAR.DeviceTree" />).</para>
<xref linkend="dbdoclet.50569368_41461" />).</para>
</entry>
</row>
<row>
@ -14345,7 +14342,7 @@

<para>This call is used obtain information about fabric configuration
addresses, given the PCI configuration address. See
<xref linkend="LoPAR.Platform" /> for more information on PEs and
<xref linkend="dbdoclet.50569330_34831" /> for more information on PEs and
determining PE configuration addresses.</para>
<para>The PCI configuration address (
<emphasis>PHB_Unit_ID_Hi, PHB_Unit_ID_Low, and config_addr</emphasis>)
@ -14617,7 +14614,7 @@
log version used, the data in the
<emphasis>Returned_Error_Buffer</emphasis> is in an extended log format as
defined in
<xref linkend="LoPAR.Error" />. When the call returns data
<xref linkend="dbdoclet.50569337_22801" />. When the call returns data
for version 6 or greater, the device driver error buffer data is included
as the last User Data section. The device driver data in the return
buffer may be truncated from what is passed by the device driver or
@ -14932,7 +14929,7 @@
<emphasis>Device_Driver_Error_Buffer_Length</emphasis> argument is
non-zero, indicating the existence of optional device driver error data,
the referenced buffer must contain an extended event log as defined in
<xref linkend="LoPAR.Error" />.</para>
<xref linkend="dbdoclet.50569337_22801" />.</para>
</listitem>
</varlistentry>

@ -16023,7 +16020,7 @@
device driver or OS from the restoration of non-interrupts the PCI
configuration space for changes that were made to the configuration space
after boot (see Requirement
<xref linkend="LoPAR.Platform" />).</para>
<xref linkend="dbdoclet.50569335_13568" />).</para>
</listitem>
</orderedlist>
</listitem>
@ -16596,7 +16593,7 @@
<emphasis role="bold"><literal>&#8220;ibm,errinjct-tokens&#8221;</literal></emphasis> property as defined
below in the
<emphasis role="bold"><literal>/rtas</literal></emphasis> node (see
<xref linkend="LoPAR.DeviceTree" />) of the OF device tree with a
<xref linkend="dbdoclet.50569368_41461" />) of the OF device tree with a
specification for each implemented error injection class.</para>
</listitem>
</varlistentry>
@ -17173,7 +17170,7 @@
<para>For PHB implementations that do not allow injection of
a TLP ECRC error into the request, or for the case where the
injection would be in violation of Requirement
<xref linkend="LoPAR.Platform" /> due to the hardware
<xref linkend="dbdoclet.50569330_20501" /> due to the hardware
configuration, the platform should emulate the error by
setting the appropriate error state in the PHB when EEH is
enabled.</para>
@ -17486,7 +17483,7 @@
should the hardware signal a machine check or system reset interrupt. The
results of an error analysis are reported via a standard error log
structure as defined in
<xref linkend="LoPAR.Error" />. The storage containing the
<xref linkend="dbdoclet.50569337_21249" />. The storage containing the
error log structure is subsequently released back to firmware use by the
OS after it has completed its event handling by the issuance, from the
interrupted processor, of the
@ -17819,7 +17816,7 @@
contains the real address of a 16 byte memory buffer containing the
original contents of GPR R3 in the first 8 bytes and the RTAS Error Log
(fixed part) (per
<xref linkend="LoPAR.Error" />) in the second 8 bytes.</para>
<xref linkend="dbdoclet.50569337_21249" />) in the second 8 bytes.</para>
</listitem>
</varlistentry>

@ -17841,7 +17838,7 @@
<para><emphasis role="bold">For the FWNMI option:</emphasis> Once the firmware has reported
a &#8220;fatal&#8221; machine check event to an OS image it must only
report &#8220;fatal error previously reported&#8221; (see
<xref linkend="LoPAR.Error" />) in response to machine checks
<xref linkend="dbdoclet.50569337_37595" />) in response to machine checks
on any processor belonging to that image.</para>
</listitem>
</varlistentry>
@ -19012,7 +19009,7 @@
<listitem>
<para>The format of the SPLPAR string is beyond the scope of this
architecture. See also,
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569367_15730" />.</para>
</listitem>

<listitem>

@ -833,7 +833,7 @@
<para>Platforms supporting the DDW option implement extensions described
in this section. These extensions include: adding the
<emphasis role="bold"><literal>&#8220;ibm,ddw-extensions&#8221;</literal></emphasis> property see
<xref linkend="LoPAR.DeviceTree" /> to those nodes that include the
<xref linkend="dbdoclet.50569368_69645" /> to those nodes that include the
<emphasis role="bold"><literal>&#8220;ibm,ddw-applicable&#8221;</literal></emphasis> property, and
implementing the functional extensions specified for the architectural
level in

@ -43,7 +43,7 @@
<para>If the LPAR option is enabled, multiple partitions may exist, each
with its own OS instance. This requires some changes to the RTAS
environment. These changes are discussed in
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569344_14591" />.</para>

<section xml:id="sec_machine_state">
<title>Machine State</title>
@ -1059,7 +1059,7 @@
</entry>
<entry morerows="1">
<para>Required for DR operations (see
<xref linkend="LoPAR.Virtualization" />)</para>
<xref linkend="dbdoclet.50569342_75822" />)</para>
</entry>
<entry>
<para>&#160;</para>
@ -1327,7 +1327,7 @@
<emphasis role="bold"><literal>&#8220;ibm,configure-connector&#8221;</literal></emphasis>
</para>
<para>
<xref linkend="LoPAR.Virtualization" />
<xref linkend="dbdoclet.50569342_39636" />
</para>
</entry>
<entry>
@ -1335,7 +1335,7 @@
</entry>
<entry>
<para>See
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569342_75822" />.</para>
</entry>
</row>
<row>
@ -1546,7 +1546,7 @@
</entry>
<entry>
<para>Sometimes (see
<xref linkend="LoPAR.Error" />)</para>
<xref linkend="dbdoclet.50569347_31867" />)</para>
</entry>
<entry>
<para>&#160;</para>
@ -1924,8 +1924,8 @@
(9003). DR indicators and sensors are required to be there based on the
DR entity being supported. Their indices are specified by the DR index
for the DR entity. See
<xref linkend="LoPAR.Virtualization" /> and
<xref linkend="LoPAR.Virtualization" /> for more information.</para>
<xref linkend="dbdoclet.50569342_92542" /> and
<xref linkend="dbdoclet.50569342_34333" /> for more information.</para>
</footnote>are static since they represent the base hardware, others are
dynamic coming and going with extensions to the base hardware. Indices
for DR indicators and sensors are obtained from the DRC index for the DRC
@ -1964,7 +1964,7 @@
contiguous, and any of the indices between 0 and
<emphasis>maxindex</emphasis> may be missing.</para>
<para>The formats for location codes are defined in
<xref linkend="LoPAR.Platform" />. For indicators and sensors,
<xref linkend="dbdoclet.50569341_35066" />. For indicators and sensors,
these location codes are for the location of the device being manipulated
or measured, not the location of the specific controller or sensor. The
location code for an abstracted indicator or sensor is a NULL
@ -1985,9 +1985,9 @@
<para>For static indicators, except DR indicators, the extension
property,
<emphasis role="bold"><literal>&#8220;</literal></emphasis><emphasis><literal>&lt;vendor&gt;</literal></emphasis><emphasis role="bold"><literal>,indicator-</literal></emphasis><emphasis><literal>&lt;token&gt;</literal></emphasis><emphasis role="bold"><literal>&#8221;</literal></emphasis>
(see <xref linkend="LoPAR.DeviceTree" />), provides an array of strings
(see <xref linkend="dbdoclet.50569368_41461" />), provides an array of strings
containing the FRU location codes associated with each indicator. See
<xref linkend="LoPAR.Platform" />. Here, &#8220;
<xref linkend="dbdoclet.50569341_35066" />. Here, &#8220;
<emphasis>&lt;vendor&gt;</emphasis>&#8221; corresponds to the
&#8220;&lt;vendor&gt;&#8221; column of
<emphasis>
@ -2007,7 +2007,7 @@
<emphasis role="bold"><literal>/rtas</literal></emphasis> node.</para>
<para>Indices for DR indicators 9001, 9002, and 9003 are obtained from
the DRC index for the DRC connector. See Requirement
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569342_16260" />.</para>

<variablelist>
<varlistentry xml:id="dbdoclet.50569332_74895">
@ -2082,9 +2082,9 @@
platform provides.</para>
<para>For static sensors, except DR sensors, the extension property,
<emphasis role="bold"><literal>&#8220;</literal></emphasis><emphasis><literal>&lt;vendor&gt;</literal></emphasis><emphasis role="bold"><literal>,sensor-</literal></emphasis><emphasis><literal>&lt;token&gt;</literal></emphasis><emphasis role="bold"><literal>&#8221;</literal></emphasis>
(see <xref linkend="LoPAR.DeviceTree" />), provides an array of strings
(see <xref linkend="dbdoclet.50569368_41461" />), provides an array of strings
containing the FRU location codes associated with each sensor. See
<xref linkend="LoPAR.Platform" />. Here, &#8220;
<xref linkend="dbdoclet.50569341_35066" />. Here, &#8220;
<emphasis>&lt;vendor&gt;</emphasis>&#8221; corresponds to the
&#8220;&lt;vendor&gt;&#8221; column of
<emphasis>
@ -2102,7 +2102,7 @@
<emphasis role="bold"><literal>/rtas</literal></emphasis> node.</para>
<para>Indices for DR sensors 9003 are obtained from the DRC index for the
DRC connector. See Requirement
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569342_43470" />.</para>

<variablelist>
<varlistentry xml:id="dbdoclet.50569332_29762">
@ -2493,7 +2493,7 @@
</entry>
<entry>
<para>Multi-level isolation error (see
<xref linkend="LoPAR.Virtualization" />).</para>
<xref linkend="dbdoclet.50569342_11827" />).</para>
</entry>
</row>
<row>

@ -36,8 +36,8 @@
OSs know which interrupts may be handled by calling
<emphasis>check-exception</emphasis>. The OF structure for describing these
interrupts is defined in
<xref linkend="LoPAR.DeviceTree"/>.
This document also defines the mask parameter for the
<xref linkend="dbdoclet.50569368_91814"/>.
<xref linkend="dbdoclet.50569337_82470"/> also defines the mask parameter for the

<emphasis>check-exception</emphasis> and
<emphasis>event-scan</emphasis> RTAS functions which limits the search for

@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2016 OpenPOWER Foundation

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
@ -13,25 +13,25 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

-->
<section xmlns="http://docbook.org/ns/docbook"
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="sec_rtas_error_reporting_loc_codes">

<title>Location Codes</title>

<para>This document defines an architecture extension for physical
location codes. One use of location codes is to append failing location
information to error logs returned by the
<emphasis>event-scan</emphasis> and
<emphasis>check-exception</emphasis> RTAS services. Refer to
<xref linkend="LoPAR.RTAS"/> for more information on the
information to error logs returned by the
<emphasis>event-scan</emphasis> and
<emphasis>check-exception</emphasis> RTAS services. Refer to
<xref linkend="dbdoclet.50569341_35066"/> for more information on the
format and use of location codes. For event logs with Version 6 or later,
the location code of FRU call out is contained in the Primary SRC
section, FRU call out sub-section of the Platform Event Log
format.</para>

</section>

@ -43,8 +43,8 @@
<para>This RTAS call is not used for DR indicators (9001, 9002, and 9003)
or DR sensors (9003). See the following sections in the DR chapter for more
information:
<xref linkend="LoPAR.Virtualization" /> and
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569342_85040" /> and
<xref linkend="dbdoclet.50569342_61130" />.</para>
<para>It may require several calls to the
<emphasis>ibm,get-indices</emphasis> RTAS routine to get the entire list of
indicators or sensors of a particular type. Each call may specify a

@ -1,7 +1,7 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2016 OpenPOWER Foundation

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
@ -13,34 +13,34 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

-->
<section xmlns="http://docbook.org/ns/docbook"
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="Hot_Plug_Events">

<title>Hot Plug Events</title>
<para>Hot Plug Events, when implemented, are reported through

<para>Hot Plug Events, when implemented, are reported through
either the event-scan RTAS call or a hotplug interrupt.</para>

<para>An OS that wants to be notified of hotplug events will need to
set the appropriate arch-vector bit. Look for the hot-plug-events
node in the /event-sources node of the OF device tree (see
<xref linkend="LoPAR.DeviceTree" />), enable the interrupts listed
in its “interrupts” property and provide an interrupt handler to call
<para>An OS that wants to be notified of hotplug events will need to
set the appropriate arch-vector bit. Look for the hot-plug-events
node in the /event-sources node of the OF device tree (see
<xref linkend="sec_papr_bindings_hot_plug_events" />), enable the interrupts listed
in its “interrupts” property and provide an interrupt handler to call
check-exception when one of those interrupts are received.</para>

<para>When a hotplug event occurs, whether reported by check-exception
or event-scan, RTAS will directly pass back the Hotplug Event Log as
<para>When a hotplug event occurs, whether reported by check-exception
or event-scan, RTAS will directly pass back the Hotplug Event Log as
described in <xref linkend="table.error.hotplug" />.</para>

<variablelist>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="Hot_Plug_Events"
<term><emphasis role="bold">R1-<xref linkend="Hot_Plug_Events"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para>If FRUs can be hot plugged in the system
@ -48,7 +48,7 @@
signaling the OS about the event.</para>
</listitem>
</varlistentry>

</variablelist>

</section>

@ -25,7 +25,7 @@

<para>Platforms may optionally preserve selected regions of storage
(LMBs) across client program boot cycles.
<xref linkend="LoPAR.Platform" /> for more information.</para>
<xref linkend="dbdoclet.50569327_70628" /> for more information.</para>

<variablelist>
<varlistentry>

@ -28,14 +28,14 @@
part of OS hibernation or migration to another platform. This RTAS call
is made by the last active processor thread of a partition. The OS uses
the H_JOIN hcall() (see
<xref linkend="LoPAR.Virtualization" />) to deactivate other
<xref linkend="dbdoclet.50569344_15933" />) to deactivate other
processing threads. Processing treads may exit H_JOIN due to an
unmaskable interrupt; if a thread has exited H_JOIN,
<emphasis>ibm,suspend-me</emphasis> fails with a status of &#8220;multiple
processor threads active&#8221;. The wake up from suspension is triggered
by partition state change (see
<xref linkend="LoPAR.Virtualization" /> sections on "Partition Migration"
and "Partition Hibernation"). The
<xref linkend="sec_vasi_partition_migration" /> and
<xref linkend="sec_vasi_partition_hibernation" />). The
<emphasis>ibm,suspend-me</emphasis> RTAS call returns only on the calling
virtual processor. Other virtual processors that were inactive when
<emphasis>ibm,suspend-me</emphasis> was called remain so until they are
@ -50,7 +50,7 @@
<emphasis>ibm,update-properties</emphasis> (see
<xref linkend="dbdoclet.50569332_40069" />) and/or
<emphasis>ibm,configure-connector</emphasis> (see
<xref linkend="LoPAR.Virtualization" />). Also during suspension, some
<xref linkend="dbdoclet.50569342_39636" />). Also during suspension, some
system parameters may have changed. See
<xref linkend="dbdoclet.50569332_10519" />, for details. The OS may want
to re-scan selected system parameters.</para>
@ -62,7 +62,7 @@
<listitem>
<para><emphasis role="bold">For the Partition Suspension option:</emphasis> The platform
must implement the Logical Partitioning option (see
<xref linkend="LoPAR.Virtualization" />)
<xref linkend="dbdoclet.50569344_14591" />)
<emphasis>.</emphasis></para>
</listitem>
</varlistentry>
@ -191,7 +191,7 @@
<listitem>
<para><emphasis role="bold">For the Partition Suspension option:</emphasis> The platform
must implement the Thread Join option (see
<xref linkend="LoPAR.Virtualization" />).</para>
<xref linkend="dbdoclet.50569344_90755" />).</para>
</listitem>
</varlistentry>

@ -236,7 +236,7 @@
<para><emphasis role="bold">For the Partition Suspension option:</emphasis> The platform
must support the &#8220;Partner partition suspended&#8221; CRQ Transport
Event (See
<xref linkend="LoPAR.Virtualization" />).</para>
<xref linkend="dbdoclet.50569348_93265" />).</para>
</listitem>
</varlistentry>

@ -273,7 +273,7 @@
<para><emphasis role="bold">For the Partition Suspension option:</emphasis> The platform
must implement the H_ENABLE_CRQ hcall() using the syntax and semantics
described in
<xref linkend="LoPAR.Virtualization" />.</para>
<xref linkend="dbdoclet.50569348_43427" />.</para>
</listitem>
</varlistentry>

@ -312,7 +312,7 @@
<listitem>
<para><emphasis role="bold">For the Partition Suspension option:</emphasis> The platform
must implement the LRDR option (See
<xref linkend="LoPAR.Virtualization" />).</para>
<xref linkend="dbdoclet.50569342_75053" />).</para>
</listitem>
</varlistentry>


@ -903,7 +903,7 @@
<row>
<entry>
<para>TLB properties (See
<xref linkend="LoPAR.DeviceTree" />)</para>
<xref linkend="dbdoclet.50569374_58783" />)</para>
</entry>
</row>
<row>

Loading…
Cancel
Save