systemsoftware
/
Linux-Architecture-Reference
35
1
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Collapse 5 subdocs back into a single document. Clean build. Tag work needed.

Browse Source 
Signed-off-by: Jeff Scheel <scheel@us.ibm.com>
pull/1/head
Jeff Scheel 5 years ago
parent 87ca3cb207
commit 26dda3f5a6
145 changed files with 10209 additions and 9258 deletions
Show Stats Download Patch File Download Diff File

0
common/app_EOD.xml → LoPAR/app_EOD.xml
Unescape Escape View File

201
Platform/app_bibliography.xml → LoPAR/app_bibliography.xml
Unescape Escape View File

@ -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,7 +13,7 @@
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:xi="http://www.w3.org/2001/XInclude"
@ -22,263 +22,262 @@
xml:id="dbdoclet.50569387_27251">
<?dbhtml stop-chunking?>
<title> Bibliography</title>
<para>This section lists documents which were referenced in this specification or which provide
additional information, and some useful information for obtaining these documents. Referenced
documents are listed below. When any of the following standards are superseded by an approved
<para>This section lists documents which were referenced in this specification or which provide
additional information, and some useful information for obtaining these documents. Referenced
documents are listed below. When any of the following standards are superseded by an approved
revision, the revision shall apply.</para>
<orderedlist>

<!-- TODO: Uncomment documents needing referencing and comment out local document -->
<!--listitem>
<para><anchor xml:id="LoPAR.Platform"
<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>

<listitem>
<para><anchor xml:id="LoPAR.DeviceTree"
<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"
<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"
<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"
<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"
<para><citetitle>Power ISA</citetitle><anchor xml:id="dbdoclet.50569387_99718"
xreflabel="Power ISA specification"/></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_45524"
<para><anchor xml:id="dbdoclet.50569387_45524"
xreflabel="IEEE Open Firmware standard"/>
<citetitle>IEEE 1275, IEEE Standard for Boot (Initialization Configuration) Firmware:
<citetitle>IEEE 1275, IEEE Standard for Boot (Initialization Configuration) Firmware:
Core Requirements and Practices</citetitle></para>
<para>IEEE part number DS02683, ISBN 1-55937-426-8</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_14175"
<para><anchor xml:id="dbdoclet.50569387_14175"
xreflabel="IEEE Open Firmware Errata specification"/>
<citetitle>Core Errata, IEEE P1275.7/D4</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_31707"
<para><anchor xml:id="dbdoclet.50569387_31707"
xreflabel="Open Firmware TFTP extensions"/>
<citetitle>Open Firmware Recommended Practice:OBP-TFTP
<citetitle>Open Firmware Recommended Practice:OBP-TFTP
Extension</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_27008"
<para><anchor xml:id="dbdoclet.50569387_27008"
xreflabel="Open Firmware Device Support Extensions specification"/>
<citetitle>Open Firmware Recommended Practice: Device
<citetitle>Open Firmware Recommended Practice: Device
Support Extensions</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_22451"
<para><anchor xml:id="dbdoclet.50569387_22451"
xreflabel="PCI Bus Binding to Open Firmware standard"/>
<citetitle>PCI Bus binding to: IEEE Std 1275-1994, Standard
<citetitle>PCI Bus binding to: IEEE Std 1275-1994, Standard
for Boot (Initialization, Configuration) Firmware</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_40740"
<para><anchor xml:id="dbdoclet.50569387_40740"
xreflabel="Open Firmware Interrupt Mapping specification"/>
<citetitle>Open Firmware: Recommended Practice - Interrupt
<citetitle>Open Firmware: Recommended Practice - Interrupt
Mapping</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_33384"
<para><anchor xml:id="dbdoclet.50569387_33384"
xreflabel="Open Firmware Forth Source and FCode Image Support specification"/>
<citetitle>Open Firmware: Recommended Practice - Forth Source
<citetitle>Open Firmware: Recommended Practice - Forth Source
and FCode Image Support</citetitle>, Version 1.0</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_67880"
<para><anchor xml:id="dbdoclet.50569387_67880"
xreflabel="Open Firmware Interrup Mapping specification"/>
<citetitle>Open Firmware: Recommended Practice - Interrupt
<citetitle>Open Firmware: Recommended Practice - Interrupt
Mapping</citetitle>, Version 1.0</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_33177"
<para><anchor xml:id="dbdoclet.50569387_33177"
xreflabel="Open Firmware TFTP Booting extensions"/>
<citetitle>Open Firmware: Recommended Practice - TFTP Booting
<citetitle>Open Firmware: Recommended Practice - TFTP Booting
Extensions</citetitle>, Version 0.8</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_27351"
<para><anchor xml:id="dbdoclet.50569387_27351"
xreflabel="Open Firmware Interposition specification"/>
<citetitle>Open Firmware: Recommended Practice -
<citetitle>Open Firmware: Recommended Practice -
Interposition</citetitle>, Version 0.2</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_22601"
<para><anchor xml:id="dbdoclet.50569387_22601"
xreflabel="MS-DOS Programmer's Reference specification"/>
<citetitle>MS-DOS Programmer's Reference</citetitle></para>
<para>Published by Microsoft</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_18190"
<para><anchor xml:id="dbdoclet.50569387_18190"
xreflabel="Win32 Executable File Format article"/>
<citetitle>Peering Inside the PE: A Tour of the Win32 Portable
<citetitle>Peering Inside the PE: A Tour of the Win32 Portable
Executable File Format</citetitle></para>
<para>Found in the March, 1994 issue of <citetitle> Microsoft Systems Journal</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_85757"
<para><anchor xml:id="dbdoclet.50569387_85757"
xreflabel="CD-ROM Volume and File Structure standard"/>
<citetitle> ISO-9660, Information processing -- Volume and
<citetitle> ISO-9660, Information processing -- Volume and
file structure of CD-ROM for information interchange</citetitle></para>
<para>Published by International Organization for Standardization</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_38836"
<para><anchor xml:id="dbdoclet.50569387_38836"
xreflabel="System V Application Binary Interface, PowerPC Processor supplement"/>
<citetitle>System V Application Binary Interface, PowerPC
<citetitle>System V Application Binary Interface, PowerPC
Processor Supplement</citetitle></para>
<para>By Sunsoft<citetitle></citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_11453"
<para><anchor xml:id="dbdoclet.50569387_11453"
xreflabel="Standard Generalized Markup Language (SGML) standard"/>
<citetitle>ISO Standard 8879:1986, Information Processing
-- Text and Office Systems -- Standard Generalized Markup Language (SGML)</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_38891"
<para><anchor xml:id="dbdoclet.50569387_38891"
xreflabel="Personal Computer Back Plane Bus standard"/>
<citetitle>IEEE 996, A Standard for an Extended Personal Computer
<citetitle>IEEE 996, A Standard for an Extended Personal Computer
Back Plane Bus</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_65468"
<para><anchor xml:id="dbdoclet.50569387_65468"
xreflabel="PCI Local Bus specification"/>
<citetitle>PCI Local Bus Specification</citetitle></para>
<para>All designers are responsible for assuring that they use the most current version of this document
at the time that they design conventional PCI related components or platforms. See the PCI SIG website
<para>All designers are responsible for assuring that they use the most current version of this document
at the time that they design conventional PCI related components or platforms. See the PCI SIG website
for the most current version of this document.</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_60429"
<para><anchor xml:id="dbdoclet.50569387_60429"
xreflabel="PCI-to-PCI Bridge Architecture specification"/>
<citetitle>PCI-to-PCI Bridge Architecture Specification</citetitle></para>
<para>All designers are responsible for assuring that they use the most current version of this document
at the time that they design conventional PCI related components or platforms. See the
<para>All designers are responsible for assuring that they use the most current version of this document
at the time that they design conventional PCI related components or platforms. See the
PCI SIG website for the most current version of this document.</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_87046"
<para><anchor xml:id="dbdoclet.50569387_87046"
xreflabel="PCI Standard Hot-Plug Controller and Subsystem specification"/>
<citetitle>PCI Standard Hot-Plug Controller and Subsystem
<citetitle>PCI Standard Hot-Plug Controller and Subsystem
Specification</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_26550"
<para><anchor xml:id="dbdoclet.50569387_26550"
xreflabel="PCI-X Protocol addendum"/>
<citetitle>PCI-X Protocol Addendum to the PCI Local Bus Specification </citetitle></para>
<para>All designers are responsible for assuring that they use the most current version of this document at
the time that they design PCI-X related components or platforms. See the PCI SIG website for the most
<para>All designers are responsible for assuring that they use the most current version of this document at
the time that they design PCI-X related components or platforms. See the PCI SIG website for the most
current version of this document.</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_66784"
<para><anchor xml:id="dbdoclet.50569387_66784"
xreflabel="PCI Express Base specification"/>
<citetitle>PCI Express Base Specification</citetitle></para>
<para>All designers are responsible for assuring that they use the most current version of this document
at the time that they design PCI Express related components or platforms. See the PCI SIG website for
<para>All designers are responsible for assuring that they use the most current version of this document
at the time that they design PCI Express related components or platforms. See the PCI SIG website for
the most current version of this document.</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_28381"
<para><anchor xml:id="dbdoclet.50569387_28381"
xreflabel="PCI Express to PCI/PCI-X Bridge specification"/>
<citetitle>PCI Express to PCI/PCI-X Bridge Specification</citetitle></para>
<para>All designers are responsible for assuring that they use the most current version of this document at the
time that they design PCI Express related components or platforms. See the PCI SIG website for the most current
<para>All designers are responsible for assuring that they use the most current version of this document at the
time that they design PCI Express related components or platforms. See the PCI SIG website for the most current
version of this document.</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_34114"
<para><anchor xml:id="dbdoclet.50569387_34114"
xreflabel="System Management BIOS reference"/>
<citetitle>System Management BIOS (SMBIOS) Reference
<citetitle>System Management BIOS (SMBIOS) Reference
Specification</citetitle></para>
</listitem>

<!-- TODO: Are the following 3 items needed? -->
<listitem>
<para><citetitle>(List Number Reserved for Compatibility)</citetitle></para>
</listitem>

<listitem>
<para><citetitle>(List Number Reserved for Compatibility)</citetitle></para>
</listitem>

<listitem>
<para><!-- anchor xml:id="dbdoclet.50569387_72648" xreflabel=""/ --><citetitle>(List Number Reserved for Compatibility)</citetitle></para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_16481"
<para><anchor xml:id="dbdoclet.50569387_16481"
xreflabel="RS/6000 Product Topology Data System and Product Development guide"/>
<citetitle>IBM RS/6000&#174; Division, Product Topology Data System,
<citetitle>IBM RS/6000&#174; Division, Product Topology Data System,
Product Development Guide</citetitle></para>
<para>Version 2.1</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_94229"
<para><anchor xml:id="dbdoclet.50569387_94229"
xreflabel="Single Root I/O Virtualization and Sharing specification"/>
<citetitle>Single Root I/O Virtualization and Sharing Specification</citetitle></para>
<para>All designers are responsible for assuring that they use the most current version of this document at
the time that they design PCI Express SR-IOV related components or platforms. See the PCI SIG website
<para>All designers are responsible for assuring that they use the most current version of this document at
the time that they design PCI Express SR-IOV related components or platforms. See the PCI SIG website
for the most current version of this document.</para>
</listitem>

<listitem>
<para><anchor xml:id="dbdoclet.50569387_42471"
<para><anchor xml:id="dbdoclet.50569387_42471"
xreflabel="Multi-Root I/O Virtualization and Sharing specification"/>
<citetitle>Multi-Root I/O Virtualization and Sharing Specification</citetitle></para>
<para>All designers are responsible for assuring that they use the most current version of this document at the
time that they design PCI Express MR-IOV related components or platforms. See the PCI SIG website for the
<para>All designers are responsible for assuring that they use the most current version of this document at the
time that they design PCI Express MR-IOV related components or platforms. See the PCI SIG website for the
most current version of this document.</para>
</listitem>

</orderedlist>

</appendix>

0
Error Handling/app_capi_error_handling.xml → LoPAR/app_capi_error_handling.xml
Unescape Escape View File

30
RTAS/ch_cmo_def.xml → LoPAR/app_cmo_def.xml
Unescape Escape View File

@ -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,27 +13,27 @@
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.

-->
<chapter xmlns="http://docbook.org/ns/docbook"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0"
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0"
xml:lang="en"
xml:id="dbdoclet.50569382_58396">

<title>CMO Characteristics Definitions</title>
<para>This chapter defines the string that is returned by the

<para>This appendix defines the string that is returned by the
<emphasis>ibm,get-system-parameter</emphasis> RTAS call when the parameter
token value of 44 (CMO Characteristics) is specified on the
<emphasis>ibm,get-system-parameter</emphasis> RTAS call as per
token value of 44 (CMO Characteristics) is specified on the
<emphasis>ibm,get-system-parameter</emphasis> RTAS call as per
<xref linkend="dbdoclet.50569332_62190"/>.</para>

<section>
<title>CMO Terms</title>
<para>The LoPAR Cooperative Memory Over-commitment option (CMO) defines
terms as presented in
terms as presented in
<xref linkend="dbdoclet.50569382_93865" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569382_93865">
@ -89,14 +89,14 @@
</tgroup>
</table>
</section>

<section>
<title>Key Words And Values</title>
<para>
<xref linkend="dbdoclet.50569382_70763" />defines the key words and the
associated legal values that will be returned in the ASCII NULL terminated
string when the parameter token value of 44 (CMO characteristics) is
specified on the
specified on the
<emphasis>ibm,get-system-parameter</emphasis> RTAS call. The key word and
value is separated by an ASCII equal (&#8220;=&#8221;). Each key word,
value pair is delimited by an ASCII comma in the string. The numerical
@ -170,4 +170,4 @@
</tgroup>
</table>
</section>
</chapter>
</appendix>

0
Platform/app_eeh_handling.xml → LoPAR/app_eeh_handling.xml
Unescape Escape View File

0
Error Handling/app_fault_v_errorlog.xml → LoPAR/app_fault_v_errorlog.xml
Unescape Escape View File

36
RTAS/ch_firmware_dump.xml → LoPAR/app_firmware_dump.xml
Unescape Escape View File

@ -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,26 +13,26 @@
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.

-->
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0"
xml:lang="en">

<title>Firmware Assisted Dump Data Format</title>

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

<section xml:id="dbdoclet.50569380__Ref135446652">
<title>Register Save Area</title>
<para>The register save area is an area in the partition&#8217;s memory
used to preserve the registers for the active CPUs during a firmware
assisted dump. The location and size of this area is specified by the
partition when firmware assisted dumpwhen it registers for firmware
assisted dump using the <xref linkend="dbdoclet.50569332_67111" />.
assisted dump using the <xref linkend="dbdoclet.50569332_67111" />.
The minimum size will be sent to the
partition in the PFDS KDUMP node.</para>
<para>The register save is a semi-free format list of registers for each
@ -43,8 +43,8 @@
<para>
<emphasis role="bold">Notes:</emphasis>
</para>
<orderedlist>

<orderedlist>
<listitem>
<para>Only CPUs that are online at the start of the Firmware Assisted
Dump will have their register data saved.</para>
@ -59,16 +59,16 @@
required to be in any specific order (To make debug easier they will most
likely be placed in ascending ASCII identifier order)</para>
</listitem>

<listitem>
<para>If the CPU is in a Transactional Memory operating mode such
that there is a valid register check point, the contents of that register
checkpoint is included with register identifiers starting with “X-”, see
<para>If the CPU is in a Transactional Memory operating mode such
that there is a valid register check point, the contents of that register
checkpoint is included with register identifiers starting with “X-”, see
<xref linkend="table_identifiers_supported" />,
else the checkpoint registers are not included.</para>
</listitem>
</orderedlist>
</orderedlist>

<table frame="all" pgwide="1">
<title>Register Save Area Format</title>
<tgroup cols="5">
@ -6278,5 +6278,5 @@
is up to the user of the save area to sort the data.</para>
<para />
</section>
</chapter>

</appendix>

0
Platform/app_glossary.xml → LoPAR/app_glossary.xml
Unescape Escape View File

1482
DeviceTree/ch_devtree_pa.xml → LoPAR/app_pa_processor_binding.xml
View File

File diff suppressed because it is too large Load Diff

48
DeviceTree/ch_devtree_system.xml → LoPAR/app_papr_binding.xml
Unescape Escape View File

@ -15,13 +15,57 @@
limitations under the License.

-->
<chapter xmlns="http://docbook.org/ns/docbook"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0"
xml:lang="en"
xml:id="dbdoclet.50569368_91814">
<title>System Binding</title>

<para>This appendix specifies the application of OF to a PAPR System, including
requirements and practices to support unique hardware and firmware specific to the
platform implementation. The core requirements and practices specified by OF must
be augmented by system-specific requirements to form a complete specification for
the firmware implementation of a PAPR System. This appendix establishes such
additional requirements pertaining to the platform and the support required by OF.</para>

<section>
<title>Overview</title>

<para>This appendix specifies the application of
<emphasis>IEEE Std 1275-1994 Standard for Boot (Initialization,
Configuration) Firmware, Core Practices and Requirements</emphasis>,
<emphasis>Core Errata, IEEE P1275.7</emphasis> and appropriate OF Standards
for LoPAR computer systems, including practices for client program
interface and data formats.</para>

<section>
<title>General Requirements for OF</title>
<para>An OF implementation for an LoPAR platform shall implement the
core requirements as defined in
<xref linkend="dbdoclet.50569387_45524" />, core errata
<xref linkend="dbdoclet.50569387_14175" />, the PA Processor-specific
extensions described in
<xref linkend="dbdoclet.50569374_59715" />, other appropriate bindings
and/or recommended practices contained in the references (see
<xref linkend="dbdoclet.50569387_27251" />), and the LoPAR Binding
specific extensions described in this appendix.</para>
<para>In addition, an OF implementation for an LoPAR platform shall
implement the
<emphasis>Device Interface</emphasis>,
<emphasis>Client Interface</emphasis> and
<emphasis>User Interface</emphasis> as defined in
<xref linkend="dbdoclet.50569387_45524" />.</para>
<para>Some LoPAR Binding property names exceed the OF Base specification
limit of 31 characters. LoPAR OF implementations shall support property
names of at least 47 characters.</para>
</section>

</section>

<xi:include href="sec_papr_binding_terms.xml"/>

<section>
<title>LoPAR Boot Flow</title>

@ -12197,4 +12241,4 @@ else

</section>

</chapter>
</appendix>

32
Virtualization/ch_platform_hcalls.xml → LoPAR/app_platform_hcalls.xml
Unescape Escape View File

@ -1,8 +1,8 @@
<chapter xmlns="http://docbook.org/ns/docbook"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdoclet.50569383_58396">
<title>Platform Dependent hcall()s</title>

<para>This chapter defines the set of hypervisor calls (hcall()s) that are
<para>This appendix defines the set of hypervisor calls (hcall()s) that are
platform dependent. The existence and/or implementation of the hcall() can
vary between firmware releases and between hardware platforms.</para>
<section>
@ -53,7 +53,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
</row>
<row>
<entry>
<para>H_GetPerformanceCounterInfo /
<para>H_GetPerformanceCounterInfo /
<xref linkend="dbdoclet.50569383_65658" xrefstyle="select: labelnumber" /></para>
</entry>
<entry>
@ -92,48 +92,48 @@ hcall ( const uint64 H_GetPerformanceCounterInfo /* Retrieve performance info */
<simplesect>
<title>Parameters:</title>

<itemizedlist>
<itemizedlist>
<listitem>
<para>size &#8211; size of the getPerformanceCounterInfoParms</para>
</listitem>

<listitem>
<para>getPerformanceCounterInfoParms &#8211; parameter list indicating
which performance counter information to retrieve.
which performance counter information to retrieve.
<xref linkend="dbdoclet.50569383_34010" /></para>
</listitem>
</itemizedlist>
</itemizedlist>
</simplesect>

<simplesect>
<title>Semantics:</title>

<itemizedlist>
<itemizedlist>
<listitem>
<para>Validate the getPerformanceInfoParms is accessible, else
H_Privilege.</para>
</listitem>

<listitem>
<para>Validate the size and contents of getPerformanceCounterInfoParms,
else H_Parameter.</para>
</listitem>

<listitem>
<para>Validate information is available for the firmware level and
platform, else H_Not_Available.</para>
</listitem>

<listitem>
<para>Validate partition is permitted to retrieve performance
information, else H_Authority.</para>
</listitem>

<listitem>
<para>Copy requested performance counters into getPerformanceInfoParms
and return H_Success.</para>
</listitem>
</itemizedlist>
</itemizedlist>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569383_34010">
<title>Performance_Counter_Info_Parms struct</title>
@ -170,7 +170,7 @@ hcall ( const uint64 H_GetPerformanceCounterInfo /* Retrieve performance info */
<para>INPUT</para>
</entry>
<entry>
<para>See
<para>See
<xref linkend="dbdoclet.50569383_64760" /></para>
</entry>
</row>
@ -252,7 +252,7 @@ hcall ( const uint64 H_GetPerformanceCounterInfo /* Retrieve performance info */
</tbody>
</tgroup>
</table>
<para>The possible values for Requested_Information are as shown in
<para>The possible values for Requested_Information are as shown in
<xref linkend="dbdoclet.50569383_64760" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569383_64760">
@ -614,4 +614,4 @@ hcall ( const uint64 H_GetPerformanceCounterInfo /* Retrieve performance info */
</simplesect>
</section>
</section>
</chapter>
</appendix>

14
Virtualization/ch_splpar.xml → LoPAR/app_splar.xml
Unescape Escape View File

@ -1,10 +1,10 @@
<chapter xmlns="http://docbook.org/ns/docbook"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title>SPLPAR Characteristics Definitions</title>
<section>
<title xml:id="dbdoclet.50569367_15730">SPLPAR Characteristics Definitions</title>

<para>This chapter defines the string that is returned by the
<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>
@ -12,7 +12,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<section>
<title>SPLPAR Terms</title>
<para>The LoPAR Shared Processor Logical Partition option (SPLPAR) defines
many terms as presented in
many terms as presented in
<xref linkend="dbdoclet.50569367_35778" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569367_35778">
@ -248,7 +248,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section>
<title>Key Words And Values</title>
<para>Table
<para>Table
<xref linkend="dbdoclet.50569367_78034" /> defines the key words and the
associated legal values that will be returned in the ASCII NULL terminated
string when the parameter token value of 20 (SPLPAR characteristics) is
@ -491,7 +491,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</tgroup>
</table>
<para><emphasis role="bold">Notes:</emphasis>
<orderedlist>
<orderedlist>
<listitem>
<para>0=Threads are not bound, 1=Threads are bound.</para>
</listitem>
@ -529,7 +529,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>0=Dedicated Donate Mode is disabled, 1=Dedicated Donate Mode is
enabled.</para>
</listitem>
</orderedlist>
</orderedlist>
</para>
</section>
</chapter>
</appendix>

222
Virtualization/ch_virtual_nic.xml → LoPAR/app_virtual_nic.xml
Unescape Escape View File

@ -1,11 +1,11 @@
<chapter xmlns="http://docbook.org/ns/docbook"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title xml:id="dbdoclet.50569384_75285">A Protocol for VNIC Communications</title>

<section>
<title>Introduction</title>
<para>The VNIC protocol defined in this chapter defines the protocol to be
used with VNIC virtual IOA, as defined in
<para>The VNIC protocol defined in this appendix defines the protocol to be
used with VNIC virtual IOA, as defined in
<xref linkend="dbdoclet.50569366_19541" />. VNIC provides a mechanism which
minimizes the number of times data is copied within the memory of the
physical system. The virtual I/O model described herein allows for either
@ -15,7 +15,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>This protocol is designed to fulfill the following
requirements:</para>

<orderedlist>
<orderedlist>
<listitem>
<para>Fast, efficient transfer and reception of Ethernet frames</para>
</listitem>
@ -60,7 +60,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<listitem>
<para>Extensible protocol for future functional additions</para>
</listitem>
</orderedlist>
</orderedlist>
</section>

<section>
@ -79,11 +79,11 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section>
<title>Zero Copy DMA Models</title>
<para>Unlike the Interpartition Logical LAN option (See
<para>Unlike the Interpartition Logical LAN option (See
<xref linkend="dbdoclet.50569348_71217" />), the VNIC protocol allows for
the physical Ethernet adapter associated with the VNIC device to securely
target memory pages associated with a VNIC adapter for virtual I/O
operations. LoPAR defines two modes of LRDMA (See
operations. LoPAR defines two modes of LRDMA (See
<xref linkend="dbdoclet.50569348_71217" />).</para>
<para>The use of Redirected RDMA is completely invisible to the VNIC
adapter, and has no impact on the VNIC protocol defined here. It is left
@ -97,21 +97,21 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<section>
<title>Protocol Overview</title>

<para>The CRQ and Sub-CRQ facilities as defined in
<para>The CRQ and Sub-CRQ facilities as defined in
<xref linkend="dbdoclet.50569348_71217" /> are used to send and receive VNIC
commands to system firmware. The different VNIC command types are defined
in
in
<xref linkend="dbdoclet.50569384_47161" />.</para>
<para>Throughout this document, boolean values assume 0 to be false, 1 to
be true. Unless otherwise specified, all lengths are expected to be given
in terms of bytes. Any setting or capability changed or enabled after a
successful H_REGISTER_CRQ will be cleared when H_FREE_CRQ is
performed.</para>
<para>The format of a VNIC command is shown in
<para>The format of a VNIC command is shown in
<xref linkend="dbdoclet.50569384_96342" />. The Command Type field of the
VNIC command is defined in
VNIC command is defined in
<xref linkend="dbdoclet.50569384_47161" />. The Return Code for a a VNIC
command is always at offset 12 in the response, as shown in
command is always at offset 12 in the response, as shown in
<xref linkend="dbdoclet.50569384_96342" />.</para>
<para>All VNIC commands have VNIC command values from 0x0 to 0x7F. Each
response to a VNIC command has a VNIC command value that is equal to the
@ -239,7 +239,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>1</para>
</entry>
<entry>
<para>This field contains a value from
<para>This field contains a value from
<xref linkend="dbdoclet.50569384_14812" />that contains the high
level return code for the operation.</para>
</entry>
@ -1515,7 +1515,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>This section gives an overview of the typical VNIC startup
sequence.</para>

<orderedlist>
<orderedlist>
<listitem>
<para>The operating system discovers a VNIC device in the device
tree.</para>
@ -1534,13 +1534,13 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<listitem>
<para>VNIC client calls H_REG_CRQ specifying the unit address and IOBA
of the CRQ page(s), and waits for either H_Success or an INITIALIZATION
message as defined in
message as defined in
<xref linkend="dbdoclet.50569348_48491" />.</para>
</listitem>

<listitem>
<para>VNIC client sends either an INITIALIZATION_COMPLETE or an
INITIALIZATION message to firmware using H_SEND_CRQ, as defined in
INITIALIZATION message to firmware using H_SEND_CRQ, as defined in
<xref linkend="dbdoclet.50569348_48491" />.</para>
</listitem>

@ -1624,7 +1624,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>The firmware will send a LOGICAL_LINK_STATE_RSP once the link
state is up.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>

<section>
@ -1633,7 +1633,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
update the firmware on the adapter, or needs to remove the virtualized
adapter from the partition, the following flows will happen.</para>

<orderedlist>
<orderedlist>
<listitem>
<para>Firmware will close its CRQ and Sub-CRQs.</para>
</listitem>
@ -1664,7 +1664,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>VNIC client opens the CRQ, and attempts the boot
sequence.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>

<section>
@ -1672,10 +1672,10 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>In the event that an active partition is migrated to a new
platform, the following sequence takes place.</para>

<orderedlist>
<orderedlist>
<listitem>
<para>VNIC client receives a TRANSPORT_EVENT event specifying Partner
Partition Suspended (Defined in
Partition Suspended (Defined in
<xref linkend="dbdoclet.50569348_93265" />).</para>
</listitem>

@ -1703,20 +1703,20 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<listitem>
<para>VNIC client attempts the boot sequence.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>

<section>
<title>Dump</title>
<para>Typical dump collection flow:</para>

<orderedlist>
<orderedlist>
<listitem>
<para>VNIC client decides on the need for a VNIC dump.</para>
</listitem>

<listitem>
<para>VNIC client sends a REQUEST_DUMP_SIZE command (see
<para>VNIC client sends a REQUEST_DUMP_SIZE command (see
<xref linkend="dbdoclet.50569384_98572" />) to system firmware.</para>
</listitem>

@ -1732,7 +1732,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</listitem>

<listitem>
<para>VNIC client sends a REQUEST_DUMP command (see
<para>VNIC client sends a REQUEST_DUMP command (see
<xref linkend="dbdoclet.50569384_42328" />) to system firmware containing
the IOBAs referring to the dump buffer.</para>
</listitem>
@ -1749,11 +1749,11 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</listitem>

<listitem>
<para>System firmware sends a REQUEST_DUMP_RSP (see
<para>System firmware sends a REQUEST_DUMP_RSP (see
<xref linkend="dbdoclet.50569384_99465" />) to the VNIC client,
indicating the dump is complete.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>

<section>
@ -1774,7 +1774,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
Sub-CRQs may be presented to either the VNIC or system firmware with a
single virtual interrupt.</para>

<orderedlist>
<orderedlist>
<listitem>
<para>Operating system chooses a VNIC adapter to use for frame
transmission.</para>
@ -1788,7 +1788,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">

<listitem>
<para>VNIC client device driver constructs a Transmit Descriptor (or
multiples) describing the TCE mapped buffer (see
multiples) describing the TCE mapped buffer (see
<xref linkend="dbdoclet.50569384_46136" />).</para>
</listitem>

@ -1810,7 +1810,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>The physical Ethernet device driver interrupts system firmware
(or system firmware polls for completion at appropriate times) indicating
the frame has been successfully transmitted. System firmware constructs a
Transmit Completion Sub-CRQ event (see
Transmit Completion Sub-CRQ event (see
<xref linkend="dbdoclet.50569384_32652" />), and places that Sub-CRQ onto
the Transmit Completion Sub-CRQ.</para>
</listitem>
@ -1819,7 +1819,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>VNIC client removes the TCE mapping for the frame, and makes it
available to its network stack.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>

<section>
@ -1838,7 +1838,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
as efficient as possible. Multiple Sub-CRQs may be presented to either
the VNIC or system firmware with a single virtual interrupt.</para>

<orderedlist>
<orderedlist>
<listitem>
<para>When the VNIC client is started, the VNIC allocates several
memory buffers to be used to the reception of Ethernet frames. The VNIC
@ -1848,7 +1848,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">

<listitem>
<para>For each receive buffer, the VNIC client creates Add Receive
Buffer Descriptor events (see
Buffer Descriptor events (see
<xref linkend="dbdoclet.50569384_19523" />), and gives them to system
firmware via the Receive Buffer Add Sub-CRQ using H_SEND_SUB_CRQ or
H_SEND_SUB_CRQ_INDIRECT. Once this is done, the VNIC client should not
@ -1872,7 +1872,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<listitem>
<para>System firmware receives an interrupt from the physical adapter
saying a frame has arrived, and uses the information it saves to generate
a Receive Completion event Sub-CRQ (see
a Receive Completion event Sub-CRQ (see
<xref linkend="dbdoclet.50569384_54724" />), and places it on the
appropriate Receive Completion Sub-CRQ.</para>
</listitem>
@ -1881,7 +1881,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>The VNIC client receives a virtual interrupt for its Receive
Completion Sub-CRQ, and passes the frame up its network stack.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>
</section>
<section>
@ -1889,7 +1889,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>All VNIC commands are sent using H_SEND_CRQ.</para>
<section xml:id="dbdoclet.50569384_34836">
<title>Version Exchange</title>
<para>The VERSION_EXCHANGE command as defined in
<para>The VERSION_EXCHANGE command as defined in
<xref linkend="dbdoclet.50569384_25438" /> allow the VNIC protocol to be
easily updated in the future. Each side is required to support the
highest common version of the VNIC protocol specification, as exchanged
@ -1972,7 +1972,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>Maximum version that VNIC client supports on a
VERSION_EXCHANGE and the maximum version that system firmware
supports on a VERSION_EXCHANGE_RSP. Each side must support the
highest common version between the two versions. A value from
highest common version between the two versions. A value from
<xref linkend="dbdoclet.50569384_19008" /> will be contained in
this field.</para>
</entry>
@ -2002,7 +2002,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -2053,7 +2053,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section xml:id="dbdoclet.50569384_72910">
<title>VNIC Capabilities</title>
<para>The VNIC capabilities command as defined in
<para>The VNIC capabilities command as defined in
<xref linkend="dbdoclet.50569384_96879" /> is used to create an abstracted
architecture for discovering and utilizing different NIC advanced
functions on adapters, in an adapter-independent manner. As new
@ -2149,7 +2149,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>2</para>
</entry>
<entry>
<para>This value should be one of the values from
<para>This value should be one of the values from
<xref linkend="dbdoclet.50569384_72718" />.</para>
</entry>
</row>
@ -2181,7 +2181,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -2400,7 +2400,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</entry>
<entry>
<para>- Query only<?linebreak?>- Boolean value returned in Number. If TRUE, TCP/IP
offload commands defined in
offload commands defined in
<xref linkend="dbdoclet.50569384_86912" /> are supported.</para>
</entry>
</row>
@ -2563,11 +2563,11 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section xml:id="dbdoclet.50569384_24033">
<title>Login Support</title>
<para>The use of the LOGIN and LOGIN_RSP commands is defined in
<para>The use of the LOGIN and LOGIN_RSP commands is defined in
<xref linkend="dbdoclet.50569384_61724" />. The format of the LOGIN
command is defined in
command is defined in
<xref linkend="dbdoclet.50569384_74952" />, and the LOGIN_RSP command is
defined in
defined in
<xref linkend="dbdoclet.50569384_17449" />.</para>
<para>There must be exactly one Transmit Submission Sub-CRQ for each
Transmit Completion Sub-CRQ, and vice versa. Each is implicitly tied to
@ -2663,7 +2663,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</entry>
<entry>
<para>This field is an I/O bus address referring to a
TCE-mapped buffer containing the LOGIN Buffer as defined in
TCE-mapped buffer containing the LOGIN Buffer as defined in
<xref linkend="dbdoclet.50569384_81443" />.</para>
</entry>
</row>
@ -3044,7 +3044,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</entry>
<entry>
<para>This field contains the number of supported Transmit
Descriptors, as detailed in
Descriptors, as detailed in
<xref linkend="dbdoclet.50569384_88683" />.</para>
</entry>
</row>
@ -3221,7 +3221,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -3249,7 +3249,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
physical port configuration authority, the VNIC client may also use the
SET_PHYS_PARMS command to change those values.</para>
<para>The SET_PHYS_PARMS, QUERY_PHYS_PARMS, and QUERY_PHYS_CAPABILITIES
commands all use a common command format defined in
commands all use a common command format defined in
<xref linkend="dbdoclet.50569384_48153" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569384_48153">
@ -3415,7 +3415,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</entry>
<entry>
<para>On a response, this is a return code for the operation as
defined in
defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -3429,7 +3429,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
parameters, the LOGICAL_LINK_STATE command and response provide a method
for the VNIC to inform system firmware when it&#8217;s ready to receive
packets. The format of the LOGICAL_LINK_STATE and LOGICAL_LINK_STATE_RSP
commands is defined in
commands is defined in
<xref linkend="dbdoclet.50569384_73732" />.</para>
<para>The current VNIC logical link state will always be returned in the
Link State field on a LOGICAL_LINK_STATE_RSP.</para>
@ -3547,7 +3547,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -3557,12 +3557,12 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section xml:id="dbdoclet.50569384_86912">
<title>TCP, UDP, and IP Offload Support</title>
<para>The QUERY_IP_OFFLOAD command as defined in
<para>The QUERY_IP_OFFLOAD command as defined in
<xref linkend="dbdoclet.50569384_90384" /> allows the VNIC client to
determine what facilities exist in the VNIC system firmware, and its
limitations, if any.</para>
<para>Based on the capabilities and limitations, the CONTROL_IP_OFFLOAD
command as defined in
command as defined in
<xref linkend="dbdoclet.50569384_70694" /> allows the VNIC client to
enable appropriate offload capabilities. QUERY_IP_OFFLOAD and
CONTROL_IP_OFFLOAD must be done prior to successful LOGIN
@ -3676,7 +3676,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>This field is an I/O bus address referring to a
TCE-mapped buffer used by system firmware to return IP offload
information. On reception of a successful QUERY_IP_OFFLOAD_RSP,
the buffer will be filled in with the structure as defined in
the buffer will be filled in with the structure as defined in
<xref linkend="dbdoclet.50569384_75230" />.</para>
</entry>
</row>
@ -3691,7 +3691,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -3791,7 +3791,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>This field is an I/O bus address referring to a
TCE-mapped buffer containing the parameters to enable or
disable TCP, UDP, and IP offload. The format of this buffer is
defined in
defined in
<xref linkend="dbdoclet.50569384_28116" />.</para>
</entry>
</row>
@ -3821,7 +3821,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -4486,9 +4486,9 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
the services in the manner it expects, it may utilize the dump support to
collect focused debugging data collected and stored in VNIC client
storage that&#8217;s been TCE-mapped.</para>
<para>The format of the REQUEST_DUMP command is defined in
<para>The format of the REQUEST_DUMP command is defined in
<xref linkend="dbdoclet.50569384_42328" />, and the format of the
REQUEST_DUMP_RSP command is defined in
REQUEST_DUMP_RSP command is defined in
<xref linkend="dbdoclet.50569384_99465" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569384_98572">
@ -4596,7 +4596,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -4831,7 +4831,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -4863,11 +4863,11 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
require decreasing the size of a different component&#8217;s trace
buffer.</para>
<para>The REQUEST_RAS_COMP_NUM and REQUEST_RAS_COMP_NUM_RSP commands are
defined in
defined in
<xref linkend="dbdoclet.50569384_60833" />, and the REQUEST_RAS_COMPS and
REQUEST_RAS_COMPS_RSP command format is defined in
REQUEST_RAS_COMPS_RSP command format is defined in
<xref linkend="dbdoclet.50569384_31394" />. The COLLECT_FW_TRACE and
COLLECT_FW_TRACE_RSP commands are defined in
COLLECT_FW_TRACE_RSP commands are defined in
<xref linkend="dbdoclet.50569384_83168" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569384_60833">
@ -4990,7 +4990,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</entry>
<entry>
<para>On a response, this field will contain a return code for
the request as defined in
the request as defined in
<xref linkend="dbdoclet.50569384_76174" />. This field is
reserved for a request.</para>
</entry>
@ -5090,7 +5090,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<entry>
<para>This field contains an I/O bus address of a TCE-mapped
buffer containing an array of Firmware Component structures as
defined in
defined in
<xref linkend="dbdoclet.50569384_79000" />. The VNIC client
should ensure the buffer is large enough to contain the number
of components as returned in a REQUEST_RAS_COMP_NUM_RSP
@ -5124,7 +5124,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -5206,7 +5206,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</entry>
<entry>
<para>This field contains a Correlator for a Firmware Component
as defined in
as defined in
<xref linkend="dbdoclet.50569384_79000" /> that this command
should act on.</para>
</entry>
@ -5300,7 +5300,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -5384,7 +5384,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</entry>
<entry>
<para>This field contains a Correlator for a Firmware Component
as defined in
as defined in
<xref linkend="dbdoclet.50569384_79000" /> that this command
should act on.</para>
</entry>
@ -5434,7 +5434,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
used to collect the trace information. On a COLLECT_FW_RSP,
this value will indicate how much trace data is actually placed
in the buffer. The trace data is an array of entries with the
format as defined in
format as defined in
<xref linkend="dbdoclet.50569384_10583" />.</para>
</entry>
</row>
@ -5449,7 +5449,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -5687,7 +5687,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>1</para>
</entry>
<entry>
<para>This field shows the current trace level, as defined in
<para>This field shows the current trace level, as defined in
<xref linkend="dbdoclet.50569384_89550" />.</para>
<para>A value of 0xFF indicates this component does not support
tracing.</para>
@ -5778,16 +5778,16 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section xml:id="dbdoclet.50569384_18536">
<title>Statistics Support</title>
<para>The REQUEST_STATISTICS command as defined in
<para>The REQUEST_STATISTICS command as defined in
<xref linkend="dbdoclet.50569384_28924" /> is used by the VNIC client to
obtain statistic counters kept by system firmware and the physical
adapter supporting the VNIC.</para>
<para>The REQUEST_STATISTICS_RSP command is defined in
<para>The REQUEST_STATISTICS_RSP command is defined in
<xref linkend="dbdoclet.50569384_78993" />.</para>
<para>In the event a given VNIC does not support the retrieval of certain
of the statistics, the statistic will have a -1 value returned in
it.</para>
<para>The REQUEST_DEBUG_STATS command defined in
<para>The REQUEST_DEBUG_STATS command defined in
<xref linkend="dbdoclet.50569384_30474" /> is used by the VNIC client to
retrieve an unarchitected block of statistics that is implementation
dependent which may be used to debug firmware problems. This is an
@ -5904,7 +5904,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<entry>
<para>This field is an I/O bus address referring to a
TCE-mapped buffer used by system firmware to place the VNIC
statistics block as defined in
statistics block as defined in
<xref linkend="dbdoclet.50569384_71370" />.</para>
</entry>
</row>
@ -6042,7 +6042,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -6520,7 +6520,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -6532,14 +6532,14 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title>Error Reporting Support</title>
<para>If system firmware encounters an error processing requests related
to the physical adapter being virtualized by the VNIC interface, it will
generate ERROR_INDICATION commands to the VNIC client, as defined in
generate ERROR_INDICATION commands to the VNIC client, as defined in
<xref linkend="dbdoclet.50569384_93668" />. The VNIC client may then, at
its discretion, obtain detailed error information using the
REQUEST_ERROR_INFO command as defined in
REQUEST_ERROR_INFO command as defined in
<xref linkend="dbdoclet.50569384_80533" />. It is the intent that the
VNIC client should log the detailed error information using its normal
error logging infrastructure and methods.</para>
<para>The REQUEST_ERROR_INFO_RSP command as defined in
<para>The REQUEST_ERROR_INFO_RSP command as defined in
<xref linkend="dbdoclet.50569384_80533" /> is used by firmware to indicate
the successful retrieval of error information. The retrieval of detailed
error information allows firmware to reuse the resources for tracking
@ -6701,7 +6701,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>2</para>
</entry>
<entry>
<para>This field contains a value as detailed in
<para>This field contains a value as detailed in
<xref linkend="dbdoclet.50569384_28607" /> showing the cause of
the error.</para>
</entry>
@ -6971,7 +6971,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -7070,7 +7070,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section xml:id="dbdoclet.50569384_64394">
<title>Link State Change</title>
<para>This LINK_STATE_INDICATION command as defined in
<para>This LINK_STATE_INDICATION command as defined in
<xref linkend="dbdoclet.50569384_57885" /> is an unacknowledged command
sent by system firmware to inform the VNIC client when the state of the
link changes. The VNIC client can also use QUERY_PHYS_PARMS at any time
@ -7204,7 +7204,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section xml:id="dbdoclet.50569384_73515">
<title>Change MAC Address</title>
<para>The CHANGE_MAC_ADDR command defined in
<para>The CHANGE_MAC_ADDR command defined in
<xref linkend="dbdoclet.50569384_89331" /> allows the VNIC client to
change the current MAC address. The request to change may fail due to
Access Control List entries set up by the administrator.</para>
@ -7313,7 +7313,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -7323,7 +7323,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section xml:id="dbdoclet.50569384_44489">
<title>Multicast Support</title>
<para>The MULTICAST_CTRL command defined in
<para>The MULTICAST_CTRL command defined in
<xref linkend="dbdoclet.50569384_45687" /> allows the VNIC client to
manage the reception of Multicast Ethernet traffic. Individual multicast
MAC addresses may be enabled and disabled, as well as all multicast
@ -7335,7 +7335,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
hardware supports it, or will enable all multicast addresses. When this
is done, system firmware will report exact matches through the unique
multicast Ethernet filter via the Exact Match bit defined in the Receive
Completion Descriptor as defined in
Completion Descriptor as defined in
<xref linkend="dbdoclet.50569384_54724" />. If the Exact Match bit is
off, and a multicast packet was returned in the Receive Completion
Descriptor, the multicast packet either matches a non-exact hashing
@ -7470,7 +7470,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -7485,10 +7485,10 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
exact adapter may change during partition mobility operations, it is
suggested this data not be relied upon operationally, and be used with
the understanding that it may change from request to request.</para>
<para>The VPD commands are defined in
<xref linkend="dbdoclet.50569384_24191" />,
<xref linkend="dbdoclet.50569384_29002" />,
<xref linkend="dbdoclet.50569384_55363" />, and
<para>The VPD commands are defined in
<xref linkend="dbdoclet.50569384_24191" />,
<xref linkend="dbdoclet.50569384_29002" />,
<xref linkend="dbdoclet.50569384_55363" />, and
<xref linkend="dbdoclet.50569384_97352" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569384_24191">
@ -7672,7 +7672,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -7891,7 +7891,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -7903,13 +7903,13 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title>Access Control Support</title>
<para>The VNIC may have certain Access Control Lists (ACLs) in effect,
and some of these may change dynamically. The ACL_CHANGE_INDICATION
command defined in
command defined in
<xref linkend="dbdoclet.50569384_25994" /> is sent by system firmware to
the VNIC client in the event any of the ACLs have changed
dynamically.</para>
<para>The ACL_QUERY command defined in
<para>The ACL_QUERY command defined in
<xref linkend="dbdoclet.50569384_78341" /> and its associated response
defined in
defined in
<xref linkend="dbdoclet.50569384_65642" /> may be used by the VNIC client
to obtain information about the ACLs in effect to enable earlier error
checking or ease of use functions.</para>
@ -8103,7 +8103,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
TCE-mapped buffer used by system firmware to place the ACL
information. Upon reception of a ACL_QUERY_RSP with a Success
return code, this buffer will be filled in with the structure
as defined in
as defined in
<xref linkend="dbdoclet.50569384_92066" /></para>
</entry>
</row>
@ -8227,7 +8227,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -8451,14 +8451,14 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</section>
<section xml:id="dbdoclet.50569384_82039">
<title>Debugging Support</title>
<para>The TUNE command defined in
<para>The TUNE command defined in
<xref linkend="dbdoclet.50569384_59278" /> may be used by the VNIC client
to opaquely pass tuning data from the VNIC client to system firmware. As
the exact firmware backing a VNIC client may change during partition
mobility operations, it is suggested this data not be relied upon
operationally, and be used with the understanding that it may change from
adapter to adapter.</para>
<para>A TUNE_RSP command defined in
<para>A TUNE_RSP command defined in
<xref linkend="dbdoclet.50569384_61084" /> will be generated by system
firmware upon completion of the TUNE command.</para>
<para>This command is an optional VNIC command, and may not be supported
@ -8675,7 +8675,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>4</para>
</entry>
<entry>
<para>This is a return code for the operation as defined in
<para>This is a return code for the operation as defined in
<xref linkend="dbdoclet.50569384_76174" />.</para>
</entry>
</row>
@ -8700,13 +8700,13 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
returned in the LOGIN response specifying all versions of transmit
descriptor supported by the VNIC. The versions of the transmit descriptor
offering the best performance appear in the array first. All VNIC
versions will support Transmit Descriptor Version Zero defined in
versions will support Transmit Descriptor Version Zero defined in
<xref linkend="dbdoclet.50569384_46136" />, but that version may not
offer the best performance.</para>
<para>Transmit Descriptor Version Two defined in
<para>Transmit Descriptor Version Two defined in
<xref linkend="dbdoclet.50569384_48728" /> is designed to be used in
combination with a previous use of Transmit Descriptor Version Zero or
Transmit Descriptor Version One defined in
Transmit Descriptor Version One defined in
<xref linkend="dbdoclet.50569384_15953" /></para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569384_46136">
@ -9058,7 +9058,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</entry>
<entry>
<para>This is an array of 5 two byte integer return codes as
defined in
defined in
<xref linkend="dbdoclet.50569384_14812" />.</para>
</entry>
</row>
@ -9582,7 +9582,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
In the event multiple Sub-CRQs are allocated for this purpose, it is the
VNIC client&#8217;s responsibility to always allocate the receive buffer
size for the Receive Buffer Add Sub-CRQs that are returned by system
firmware as defined in
firmware as defined in
<xref linkend="dbdoclet.50569384_97019" />.</para>
<para>System firmware will configure the correct buffer sizes based on
the current VNIC maximum transmission unit, current number of Receive
@ -9887,4 +9887,4 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">

</section>
</section>
</chapter>
</appendix>

34
Virtualization/ch_virtual_scsi.xml → LoPAR/app_virtual_scsi.xml
Unescape Escape View File

@ -1,10 +1,10 @@
<chapter xmlns="http://docbook.org/ns/docbook"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdoclet.50569379_75285">
<title>A Protocol for VSCSI Communications</title>

<section>
<title>Introduction</title>
<para>The purpose of this chapter is to define the protocol used by
<para>The purpose of this appendix is to define the protocol used by
virtual SCSI (vscsi) client drivers and vscsi server drivers in sufficient
detail to ensure compatibility between unlike operating systems
implementing these features. The SCSI Architecture Model (SAM-2) defines
@ -258,25 +258,25 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
communication are required to perform virtual SCSI functions.</para>
<para>These communications are made up of three classes of messages:</para>

<itemizedlist>
<itemizedlist>
<listitem>
<para>Messages contained entirely within a single CRQ message</para>
</listitem>

<listitem>
<para>SRP requests and responses, as defined by the SRP standard</para>
</listitem>

<listitem>
<para>Management Datagrams</para>
</listitem>
</itemizedlist>
</itemizedlist>
</section>
<section>
<title>CRQ Message formats</title>
<para>CRQ messages are 16 bytes (128 bits) in length. Only the first byte
is architected by the Reliable Command/Response Transport specification
described earlier in this document. That specification is repeated in
described earlier in this document. That specification is repeated in
<xref linkend="dbdoclet.50569379_71481" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569379_71481">
@ -345,7 +345,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<para>If the first byte of a CRQ message is 0x80, then it is a valid
Command/Response entry and the second byte describes the format of message.
Possible values for the second byte of the CRQ message when the first byte
is 0x80 are shown in
is 0x80 are shown in
<xref linkend="dbdoclet.50569379_38069" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569379_38069">
@ -434,9 +434,9 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
</table>
<para>If the format byte is 0x01, then the rest of the message is a vscsi
SRP request or response message. The rest of the CRQ contents for this type
of message is shown in
of message is shown in
<xref linkend="dbdoclet.50569379_60771" />, for messages from the clients,
and
and
<xref linkend="dbdoclet.50569379_58834" />, for messages from the VIOS.
Messages with a format byte of 0x02 are Management Datagram messages,
defined later in this chapter. Messages formats of 0x03, 0x04, and 0x05
@ -446,7 +446,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
</section>
<section>
<title>CRQ VSCSI Client Message Format</title>
<para>Client messages are sent from the client partitions to the VIOS.
<para>Client messages are sent from the client partitions to the VIOS.
<xref linkend="dbdoclet.50569379_60771" /> shows the format of these
messages,</para>

@ -549,7 +549,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<section>
<title>CRQ VSCSI VIOS Message Format</title>
<para>VIOS messages are sent from the VIOS to the clients, usually in
response to a request from the client. The VIOS message format is shown
response to a request from the client. The VIOS message format is shown
<xref linkend="dbdoclet.50569379_58834" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569379_58834">
@ -735,7 +735,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<para>The inter_op structure is used to specify the type of MAD being
sent.</para>

<programlisting><![CDATA[typedef struct _inter_op_fields{
<programlisting><![CDATA[typedef struct _inter_op_fields{
uint32_t type;
uint16_t status;
uint16_t length;
@ -751,7 +751,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<programlisting><![CDATA[#define MAD_SUCCESS 0x0
#define MAD_NOT_SUPPORTED 0xF1
#define MAD_FAILED 0xF7]]></programlisting>

<para>MAD_NOT_SUPPORTED is returned if the VIOS is down-level. MAD_FAILED
is returned in every other situation where the MAD did not succeed.</para>
<para>The length field is set to the length of the data structure(s) used
@ -808,7 +808,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<para>The MAD_ERROR_LOGGING_REQUEST uses the following data
structure:</para>

<programlisting><![CDATA[struct mad_error_logging_request{
<programlisting><![CDATA[struct mad_error_logging_request{
inter_op op;
uint64_t buffer;
};]]></programlisting>
@ -875,7 +875,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<para>The MAD_ADAPTER_INFO_REQUEST uses the following data
structure:</para>

<programlisting><![CDATA[struct mad_adapter_information_request{
<programlisting><![CDATA[struct mad_adapter_information_request{
inter_op op;
uint64_t buffer;
};]]></programlisting>
@ -1195,4 +1195,4 @@ unsigned int cap_type;

</section>
</section>
</chapter>
</appendix>

6
Virtualization/ch_virtual_tpm.xml → LoPAR/app_virtual_tpm.xml
Unescape Escape View File

@ -15,13 +15,13 @@
limitations under the License.

-->
<chapter xmlns="http://docbook.org/ns/docbook"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="ch_virtual_trusted_platform_module">
<title>Virtual Trusted Platform Module (VTPM)</title>

<section>
<title>A protocol for VTPM communications</title>
<para>The protocol defined in this section is to be used with the VTPM as defined in
<para>The protocol defined in this appendix is to be used with the VTPM as defined in
<xref linkend="sec_virtual_trusted_platform_module" />.
The VTPM provides the services of a TPM device to an associated client partition,
the primary use of a VTPM is to enable software in the partition to perform a
@ -2369,4 +2369,4 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="ch_v
</section>
</section>
</section>
</chapter>
</appendix>

46
Virtualization/ch_virtual_tty.xml → LoPAR/app_virtual_tty.xml
Unescape Escape View File

@ -1,15 +1,15 @@
<chapter xmlns="http://docbook.org/ns/docbook"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdoclet.50569375_64200">
<title>A Protocol for a Virtual TTY Interface</title>

<section>
<title>Overview</title>
<para>This chapter defines a protocol to support partition use of a
<para>This appendix defines a protocol to support partition use of a
physical serial port using a virtual TTY (VTY) interface. A protocol is
required to send control and status information of the physical device
using a data only transport.</para>
<para>Specifically, this protocol is used to allow the Virtual Terminal
(VTERM) option, as defined in
(VTERM) option, as defined in
<xref linkend="dbdoclet.50569352_15379" />, as the interface to communicate
with a physical serial port which is under control of the platform instead
of the OS.</para>
@ -45,11 +45,11 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo

<section>
<title>Data Packet</title>

<programlisting><![CDATA[#define VS_DATA_PACKET_HEADER 0xFF]]></programlisting>

<para>This packet type is used to send data.</para>
<para>The data packet is defined in
<para>The data packet is defined in
<xref linkend="dbdoclet.50569375_39781" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569375_39781">
@ -137,7 +137,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<para>This packet type is used to send commands that control the
operation of software or hardware on the other side of the link, and to
send notification of status changes on the other side.</para>
<para>The control packet is defined in
<para>The control packet is defined in
<xref linkend="dbdoclet.50569375_94407" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569375_94407">
@ -237,7 +237,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
partition to the platform.</para>
<para>
<emphasis role="bold">Data Member Definition:</emphasis> The data member for this verb
consists of 8 bytes, as defined in
consists of 8 bytes, as defined in
<xref linkend="dbdoclet.50569375_31856" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569375_31856">
@ -302,7 +302,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
be serialized with data packets.</para>
<para>In the data portion of the packet, the first word defines the bit
values to be set; the second word is a mask defining which bits are to be
updated. See
updated. See
<xref linkend="dbdoclet.50569375_21059" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569375_21059">
@ -392,7 +392,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
to the partition.</para>
<para>
<emphasis role="bold">Data Member Definition:</emphasis> The data member for this verb
consists of 4 bytes, as defined in
consists of 4 bytes, as defined in
<xref linkend="dbdoclet.50569375_44278" /></para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569375_44278">
@ -439,9 +439,9 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<para>This packet is sent by platform to the partition to inform the
partition of a change in status of certain bits in the VS_MODEM_CTL word.
The bits which cause this command to be sent when they transition are
defined in
defined in
<xref linkend="dbdoclet.50569375_17217" />. This command should be
serialized with data packets. The protocol version in
serialized with data packets. The protocol version in
<xref linkend="dbdoclet.50569375_17217" /> defines the first (lowest)
version of the protocol in which a transition of this bit should cause
the command to be sent.</para>
@ -524,7 +524,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
below. There is in some case implied control of the state of the other
side of the link, as a series of queries and responses are used to
initialize (or re-initialize) the protocol.</para>
<para>The query packet is defined in
<para>The query packet is defined in
<xref linkend="dbdoclet.50569375_12777" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569375_12777">
@ -635,7 +635,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo

<para>This packet is used to reply to query packets sent from the other
side of the link, and are sent only in response to query packets.</para>
<para>The query response packet is defined in
<para>The query response packet is defined in
<xref linkend="dbdoclet.50569375_51311" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569375_51311">
@ -799,7 +799,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
<section>
<title>Packet Type and Verb Summary</title>
<?dbhtml table-width="75%" ?><?dbfo table-width="75%" ?>
<para>A summary of packet types and verbs can be found in
<para>A summary of packet types and verbs can be found in
<xref linkend="dbdoclet.50569375_88851" />.</para>

<table frame="all" pgwide="1" xml:id="dbdoclet.50569375_88851">
@ -993,40 +993,40 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
discarded.</para>
<para>The connection process is initiated by the partition side. The
sequence is as follows:</para>
<itemizedlist>
<itemizedlist>
<listitem>
<para>Both sides are in closed state. Both side are
&#8220;listening&#8221; to the VTY.</para>
</listitem>

<listitem>
<para>The partition sends the VSV_SEND_VERSION_NUMBER query.</para>
</listitem>

<listitem>
<para>The partition continues listening, but discard any packet that is
not a VSV_SEND_VERSION_NUMBER query response.</para>
</listitem>

<listitem>
<para>The platform replies with the VSV_SEND_VERSION_NUMBER query
response packet.</para>
</listitem>

<listitem>
<para>The platform clears any pending data in the serial port
hardware.</para>
</listitem>

<listitem>
<para>The platform sends the VSV_SEND_VERSION_NUMBER query packet.</para>
</listitem>

<listitem>
<para>The partition responds with the VSV_SEND_VERSION_NUMBER query
response packet.</para>
</listitem>
</itemizedlist>
</itemizedlist>
<para>At this point the protocol is open; any data received in the serial
hardware by the platform from this point should be put into data packets
and sent to the partition; any data packets received from the partition
@ -1038,4 +1038,4 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en" xml:id="dbdo
device tree node to communicate an appropriate time-out value.</para>

</section>
</chapter>
</appendix>

32
Virtualization/ch_vmc_comm.xml → LoPAR/app_vmc_comm.xml
Unescape Escape View File

@ -1,4 +1,4 @@
<chapter xmlns="http://docbook.org/ns/docbook"
<appendix xmlns="http://docbook.org/ns/docbook"
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<title>A Protocol for VMC Communications</title>

@ -38,13 +38,13 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
when the system is not HMC managed.</para>
<para>This communication device borrows aspects from both VSCSI and ILLAN
devices and is implemented using the CRQ and the RDMA interfaces. The
initialization process for CRQs is defined in
initialization process for CRQs is defined in
<xref linkend="dbdoclet.50569348_71217" />, and is not duplicated here. A
three way handshake is defined that must take place to establish that
both the hypervisor and management partition sides of the channel are
running prior to sending/receiving any of the protocol messages defined
in this chapter.</para>
<para>Transport Event CRQs are also defined in
<para>Transport Event CRQs are also defined in
<xref linkend="dbdoclet.50569348_71217" />, and are not duplicated here.
They define the CRQ messages that are sent when the hypervisor detects
one of the peer partitions has abnormally terminated, or one side has
@ -194,7 +194,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
exchange of capabilities has completed are dropped.</para>
<para>This message enables the management partition and the hypervisor to
trade the following interface parameters:</para>
<orderedlist>
<orderedlist>
<listitem>
<para># HMC&#8217;s. Maximum number of independent HMC connections
supported. Multiple connections would be required to support HMC pass
@ -221,9 +221,9 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
the hypervisor with the high-order byte indicating a major version and
the low-order byte indicating a minor version.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>

<section>
<title>VMC Capabilities Response</title>

@ -241,7 +241,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<colspec colname="c8" colwidth="11*" align="center" />
<colspec colname="c9" colwidth="11*" align="center" />
<tbody>
<row>
<row>
<entry>
<para>1 B</para>
</entry>
@ -323,7 +323,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
and the hypervisor. Many of the HMC Interface messages defined in
following sections indicate buffers that contain data that must be
transferred. Note the following:</para>
<orderedlist>
<orderedlist>
<listitem>
<para>All buffers exist in the hypervisor memory, and data is moved
between the hypervisor and the management partition by the management
@ -377,16 +377,16 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>There is a separate buffer pool for each LPM connection, each
with the negotiated number of buffers.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>

<section>
<title>HMC Interface Messages</title>
<para>There are several different HMC Interface messages, as defined in
the following sections. Each CRQ message has a unique HMC Interface
message type, and the HMC Interface message type defines the format for
the remaining 14 bytes of data.</para>

<section>
<title>Interface Open</title>

@ -795,7 +795,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
and to 1 if the buffer being added is to be used for messages outbound
from the hypervisor.</para>
<para>The typical flow for adding buffers:</para>
<orderedlist>
<orderedlist>
<listitem>
<para>A new LPM connection is opened by the management
partition.</para>
@ -817,7 +817,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
application that it has buffers available for sending HMC
commands.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>
<section>
<title>Add Buffer Response</title>
@ -980,7 +980,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>The hypervisor is expected to manage buffer usage with the LPM
application directly and inform the management partition when buffers may
be removed. The typical flow for removing buffers:</para>
<orderedlist>
<orderedlist>
<listitem>
<para>The LPM application no longer needs a communication path to a
particular hypervisor function. That function is closed.</para>
@ -1006,7 +1006,7 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
<para>The management partition verifies it can remove the buffer. This
is possible if buffers have been quiesced.</para>
</listitem>
</orderedlist>
</orderedlist>
</section>
<section>
<title>Remove Buffer Response</title>
@ -1298,4 +1298,4 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</figure>
</section>
</section>
</chapter>
</appendix>

386
LoPAR/bk_main.xml
Unescape Escape View File

@ -0,0 +1,386 @@
<?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

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
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.

-->
<book 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"
xml:id="bk_main">

<!-- TODO: When ready to publish document, remove the 'status="draft"' statement from the book object above. -->

<title>Linux on Power Architecture Reference</title>
<subtitle>A PAPR Linux Subset</subtitle>

<info>
<author>
<personname>
<surname>System Software Work Group</surname>
</personname>
<email>syssw-chair@openpowerfoundation.org</email>
<affiliation>
<orgname>OpenPOWER Foundation</orgname>
</affiliation>
</author>
<copyright>
<year>2016, 2018, 2020</year>
<holder>OpenPOWER Foundation</holder>
</copyright>
<!-- TODO: Set the correct document releaseinfo -->
<releaseinfo>Revision 0.5_pre6</releaseinfo>
<productname>OpenPOWER</productname>
<pubdate/>

<legalnotice role="apache2">

<annotation>
<remark>Copyright details are filled in by the template.</remark>
</annotation>
</legalnotice>

<!-- TODO: Update the following text with the correct document description (first paragraph),
Work Group name, and Work Product track (both in second paragraph). -->
<abstract>
<para>The purpose of this document is to provide firmware and software
architectural details associated with an OpenPOWER Systems.
The base content for this document were contributed to the OpenPOWER Foundation in the
<citetitle>IBM Linux on Power Architecture Platform Reference (LoPAPR) Draft</citetitle>
document which detailed Linux running on PowerVM. While this information is not always
immediately applicable to new OpenPOWER modes of bare metal or KVM, many of the
concepts and interfaces remain in some form. Until such time as the document addresses
these new OpenPOWER modes and components, it will remain versioned less than 1.0. It should
also be noted that the original document had numerous contributors inside IBM.</para>

<para>This document is a Standard Track, Work Group Specification work product owned by the
System Software Workgroup and handled in compliance with the requirements outlined in the
<citetitle>OpenPOWER Foundation Work Group (WG) Process</citetitle> document. It was
created using the <citetitle>Master Template Guide</citetitle> version 0.9.5. Comments,
questions, etc. can be submitted to the public mailing list for this document at
<link xlink:href="mailto:syssw-linux_architecture_ref@mailinglist.openpowerfoundation.org">syssw-linux_architecture_ref@mailinglist.openpowerfoundation.org</link>.</para>
</abstract>

<revhistory>
<!-- TODO: Update as new revisions created -->
<revision>
<date>2020-04-20</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Revision 0.5_pre6 - Re-merge 5 sub-docs back into one matching PAPR. No technical updates.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2020-04-06</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Revision 0.5_pre5 - Updates to include latest PAPR ACRs (2.9) as follows:</para>
<itemizedlist spacing="compact">
<listitem>
<para>Add H_VIOCTL subfunctions for VNIC failover support</para>
</listitem>
<listitem>
<para>Add H_VIOCTL subfunction for virtual ethernet MAC scan functionality</para>
</listitem>
<listitem>
<para>Add H_VIOCTL subfunctions for virtual scsi and FC mobility preparation functionality</para>
</listitem>
<listitem>
<para>ibm,current-associativity-domain property</para>
</listitem>
<listitem>
<para>HPT resizing option - KVM only</para>
</listitem>
<listitem>
<para>Add Coherent Platform Facilities (CAPI)</para>
</listitem>
<listitem>
<para>XIVE Exploitation</para>
</listitem>
<listitem>
<para>Add 'OCC online/offline' events to 'IE' error log subsection</para>
</listitem>
<listitem>
<para>LPM Redundancy Phase II: Redundancy</para>
</listitem>
<listitem>
<para>Add optional sub-queue support to VFC on P9 and newer</para>
</listitem>
<listitem>
<para>Increase max num-entries for H_SEND_SUB_CRQ_INDIRECT to 128</para>
</listitem>
<listitem>
<para>Add Virtual Serial Multiplex adapter interfaces</para>
</listitem>
<listitem>
<para>Maximum size of Dispatch Trace Log Buffer</para>
</listitem>
<listitem>
<para>Eliminate requirement for clearing TCP checksum field for ILLAN checksum calculation</para>
</listitem>
<listitem>
<para>Continued Extension of H_Send_Logical_LAN for large send packets</para>
</listitem>
<listitem>
<para>Add LPM Capablity keyword to RTAS AIX Support system parameter</para>
</listitem>
<listitem>
<para>XIVE Exploitation addition: Add ESB Reset Status to RTAS ibm,read-slot-reset-state2</para>
</listitem>
<listitem>
<para>Add NVDIMM Protection and Encryption State system parameters</para>
</listitem>
<listitem>
<para>Change or Remove 0x9 and 0xA event subtypes for 'IE' error log subsection</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>Additional, post PAPR 2.9 ACRs as follows:</para>
<itemizedlist spacing="compact">
<listitem>
<para>Reserve a range of hcalls to to support Ultravisor</para>
</listitem>
<listitem>
<para>Add New CAS Bit For SRIOV Virtual Function (VF) Dynamic DMA Window (DDW) Support</para>
</listitem>
<listitem>
<para>Updates to support vTPM 2.0</para>
</listitem>
<listitem>
<para>Update XIVE Legacy hcalls to add H_Function</para>
</listitem>
<listitem>
<para>Add NVDIMM Secure Erase Command system parameter</para>
</listitem>
<listitem>
<para>Update H_REGISTER_VPA to add H_STATE return code for VPA and SLB shadow buffer.</para>
</listitem>
<listitem>
<para>Extend Firmware Assisted Dump for ISA Version 3.0</para>
</listitem>
<listitem>
<para>Add a new return code, H_NOT_AVAILABLE, to start-cpu rtas call</para>
</listitem>
<listitem>
<para>Document already-implemented NVRAM variables</para>
</listitem>
<listitem>
<para>Update ibm,dynamic-memory-vN flags to include a "Hotplugged Memory" flag</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2019-01-08</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Revision 0.5_pre4 - Update document type to Work Group Note. Final review ready.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2018-07-30</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Revision 0.5_pre3 - Updates to documentation in preparation for System SW WG review:</para>
<orderedlist spacing="compact">
<listitem>
<para>Reset document version to 0.5</para>
</listitem>
<listitem>
<para>Improved Abstract</para>
</listitem>
</orderedlist>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2017-10-11</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Revision 2.0_pre2 - Updates to include latest PAPR ACRs (2.8) as follows:</para>
<itemizedlist spacing="compact">
<listitem>
<para>ISA 2.07 privileged doorbell extensions (9/16/2012)</para>
</listitem>
<listitem>
<para>POWER ISA Name Change Category Vector.XOR to Vector.CRYPTO (11/4/2012)</para>
</listitem>
<listitem>
<para>Enable Multiple Redirected RDMA mappings per page (3/5/2013)</para>
</listitem>
<listitem>
<para>Add Block Invalidate Option (3/5/2013)</para>
</listitem>
<listitem>
<para>Implementation Dependent Optimizations (3/13/2013)</para>
</listitem>
<listitem>
<para>System Firmware Service Entitlement Date (Warranty Date) Check (4/3/2013)</para>
</listitem>
<listitem>
<para>New Function for ibm,change-msi to specify 32 bit MSI (5/14/2013)</para>
</listitem>
<listitem>
<para>Remove Client-Architecture-Support bit for UUID option (4/16/2013)</para>
</listitem>
<listitem>
<para>AddClient Architecture Support bit for RTAS ibm,change-msi (5/28/2013)</para>
</listitem>
<listitem>
<para>Add VNIC Server (5/24/2014)</para>
</listitem>
<listitem>
<para>VPA changes for P8 (EBB) (5/24/2013)</para>
</listitem>
<listitem>
<para>Add an hcall to clean up the entire MMU hashtable (11/20/2013)</para>
</listitem>
<listitem>
<para>Add LPCR[ILE] support to H_SET_MODE (5/31/2013)</para>
</listitem>
<listitem>
<para>New Root Node Properties (1/12/2016)</para>
</listitem>
<listitem>
<para>Extended Firmware Assisted Dump for P8 Registers (1/24/2014)</para>
</listitem>
<listitem>
<para>Sufficient H_COP_OP output buffer (6/21/2014)</para>
</listitem>
<listitem>
<para>Extend H_SEND_LOGICAL_LAN for large send packets (6/29/2014)</para>
</listitem>
<listitem>
<para>Extend H_GET_MPP_X reporting coalesced pages (8/24/2014)</para>
</listitem>
<listitem>
<para>Update ibm,pcie-link-speed-stats property to support PCIe 3.0 link speeds (6/12/2015)</para>
</listitem>
<listitem>
<para>Extend ibm,get-system-parameters RTAS to report Energy Management Tuning Parameters (3/18/2015)</para>
</listitem>
<listitem>
<para>Additional System Parameters related to mgmt of FW Service Entitlement Warranty period (6/22/2015)</para>
</listitem>
<listitem>
<para>Additional System Parameter to read LPAR Name string (10/7/2015)</para>
</listitem>
<listitem>
<para>Redesign of properties for DRC information and dynamic memory (7/23/2015)</para>
</listitem>
<listitem>
<para>Add additional logical loction code sections (3/4/2016)</para>
</listitem>
<listitem>
<para>Add ibm,vnic-client-mac to support vNIC failover (2/29/2016)</para>
</listitem>
<listitem>
<para>hcall for registering the process table (3/21/2016)</para>
</listitem>
<listitem>
<para>New device tree property for UUID (3/21/2016)</para>
</listitem>
<listitem>
<para>Changes for Hotplug RTAS Events (10/24/2016)</para>
</listitem>
<listitem>
<para>Support 64-bit PE TCEs in ibm,query-pe-dma-window (7/14/2016)</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2016-05-04</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Revision 2.0_pre1 - initial conversion from IBM document. Extracted from
Linux on Power Architecture Platform Reference (LoPAPR) version 1.1 dated March 24,
2016 -- Chapter 1 (Introduction), Chapter 2 (System Requirements),
Chapter 3 (Address Map), Chapter 4 (I/O Bridges and Topology),
Chapter 5 (Processors and Memory), Chapter 6 (Interrupt Controller),
Chapter 8 (Non-volatile memory), Chapter 9 (I/O Devices),
Chapter 11 (The Symmetric Multiprocessor Option), Chapter 12 (Product Topology),
and Appendix H (Non-Uniform Memory Access [NUMA] Option).</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
</revhistory>
</info>

<!-- The ch_preface.xml file is required by all documents -->
<xi:include href="../../Docs-Master/common/ch_preface.xml"/>
<xi:include href="ch_LoPAPR_preface.xml"/>

<!-- Chapter heading files -->
<xi:include href="ch_introduction.xml"/>
<xi:include href="ch_system_reqs.xml"/>
<xi:include href="ch_address_map.xml"/>
<xi:include href="ch_processors_memory.xml"/>
<xi:include href="ch_io_topology.xml"/>
<xi:include href="ch_interrupt_controller.xml"/>
<xi:include href="ch_rtas.xml"/>
<xi:include href="ch_nonvolatile_memory.xml"/>
<xi:include href="ch_io_devices.xml"/>
<xi:include href="ch_notifications.xml"/>
<xi:include href="ch_smp.xml"/>
<xi:include href="ch_product_topology.xml"/>
<xi:include href="ch_dynamic_reconfig.xml"/>
<xi:include href="ch_lpar_option.xml"/>
<xi:include href="ch_numa.xml"/>
<xi:include href="ch_service_indicators.xml"/>
<xi:include href="ch_virtual_io.xml"/>

<!-- Document specific appendices -->
<xi:include href="app_splar.xml"/>
<xi:include href="app_papr_binding.xml"/>
<xi:include href="app_pa_processor_binding.xml"/>
<xi:include href="app_virtual_tty.xml"/>
<xi:include href="app_virtual_scsi.xml"/>
<xi:include href="app_vmc_comm.xml"/>
<xi:include href="app_firmware_dump.xml"/>
<xi:include href="app_eeh_handling.xml"/>
<xi:include href="app_cmo_def.xml"/>
<xi:include href="app_platform_hcalls.xml"/>
<xi:include href="app_virtual_nic.xml"/>
<xi:include href="app_virtual_tpm.xml"/>
<xi:include href="app_fault_v_errorlog.xml"/>
<xi:include href="app_capi_error_handling.xml"/>

<xi:include href="app_bibliography.xml"/>
<xi:include href="app_glossary.xml"/>

<!-- The app_foundation.xml appendix file is required by all documents. -->
<xi:include href="../../Docs-Master/common/app_foundation.xml"/>

<xi:include href="app_EOD.xml"/>

</book>

14
common/ch_LoPAR_preface.xml → LoPAR/ch_LoPAPR_preface.xml
Unescape Escape View File

@ -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,7 +13,7 @@
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.

-->
<preface xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
@ -23,9 +23,9 @@
<title>About This Document</title>
<?dbhtml stop-chunking?>

<xi:include href="sec_LoPAR_goals.xml"/>
<xi:include href="sec_LoPAR_audience.xml"/>
<xi:include href="sec_LoPAR_reading.xml"/>
<xi:include href="sec_LoPAR_conventions.xml"/>
<xi:include href="sec_LoPAPR_goals.xml"/>
<xi:include href="sec_LoPAPR_audience.xml"/>
<xi:include href="sec_LoPAPR_reading.xml"/>
<xi:include href="sec_LoPAPR_conventions.xml"/>

</preface>

0
Platform/ch_address_map.xml → LoPAR/ch_address_map.xml
Unescape Escape View File

454
Virtualization/ch_dynamic_reconfig.xml → LoPAR/ch_dynamic_reconfig.xml
Unescape Escape View File

@ -4205,252 +4205,252 @@ xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
</varlistentry>
</variablelist>
</section>

<section xml:id="sec_isolation_of_coherent_platform_facilities">
<title>Isolation of Coherent Platform Facilities</title>

<para>Isolation of a Coherent Platform Facility (COPLATFAC) disconnects the OS
image from any of the DR connectors downstream (Coherent Platform Functions or
COPLATFUN) of the Coherent Platform Facility. To avoid the complex- ity of
gracefully managing multi-level isolation, isolation is restricted to only
“leaf” DR connectors, that is connectors that have no unisolated or usable DR
connectors below them. All COPLATFUN connectors must return unusable state (2)
during get-sensor-state before a COPLATFAC can be isolated, this is done through
set-indicator (isolation-state, isolate). The OS is responsible for removing all
memory mappings and detaching all processes potentially in use by co- herent
platform functions. If valid mappings or processes are found, the set-indicator
does not change the isolation state and returns with a Status -9001 (Valid
outstanding translation).</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_isolation_of_coherent_platform_facilities"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a
request to <emphasis>set-indicator</emphasis> (isolation-state, isolate)
would result in the isolation of one or more other DR connectors
which are currently unisolated or usable, then the
<emphasis>set-indicator</emphasis> RTAS must fail with a return code of
“Multi-level isolation error” (-9000).</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_isolation_of_coherent_platform_facilities"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the LRDR option combined with the LPAR
option:</emphasis> The RTAS <emphasis>set-indicator</emphasis> specifying
isolate isolation-state of a COPLATFUN DR connector type must check that
all processes associated with the function are detached, else the RTAS
routine must return with a Status -9001 (Valid outstanding translation)
and the isolation-state is not changed.</para>
</listitem>
</varlistentry>
</variablelist>

</section>
</section>
</section>

<section xml:id="sec_isolation_of_coherent_platform_facilities">
<title>Isolation of Coherent Platform Facilities</title>

<para>Isolation of a Coherent Platform Facility (COPLATFAC) disconnects the OS
image from any of the DR connectors downstream (Coherent Platform Functions or
COPLATFUN) of the Coherent Platform Facility. To avoid the complex- ity of
gracefully managing multi-level isolation, isolation is restricted to only
“leaf” DR connectors, that is connectors that have no unisolated or usable DR
connectors below them. All COPLATFUN connectors must return unusable state (2)
during get-sensor-state before a COPLATFAC can be isolated, this is done through
set-indicator (isolation-state, isolate). The OS is responsible for removing all
memory mappings and detaching all processes potentially in use by co- herent
platform functions. If valid mappings or processes are found, the set-indicator
does not change the isolation state and returns with a Status -9001 (Valid
outstanding translation).</para>
<section xml:id="sec_set_indicator">
<title><emphasis>set-indicator</emphasis> (dr-indicator)</title>
<para>Logical connectors do not have associated dr-indicators (token
value 9002). An attempt to set the state of such an indicator results in
a &#8220;No such indicator implemented&#8221; return status.
</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_isolation_of_coherent_platform_facilities"
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_set_indicator"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a
request to <emphasis>set-indicator</emphasis> (isolation-state, isolate)
would result in the isolation of one or more other DR connectors
which are currently unisolated or usable, then the
<emphasis>set-indicator</emphasis> RTAS must fail with a return code of
“Multi-level isolation error” (-9000).</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_isolation_of_coherent_platform_facilities"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis role="bold">For the LRDR option combined with the LPAR
option:</emphasis> The RTAS <emphasis>set-indicator</emphasis> specifying
isolate isolation-state of a COPLATFUN DR connector type must check that
all processes associated with the function are detached, else the RTAS
routine must return with a Status -9001 (Valid outstanding translation)
and the isolation-state is not changed.</para>
<para><emphasis role="bold">For all LRDR options:</emphasis> The calling of
<emphasis>set-indicator</emphasis> with a token value of 9002
(dr-indicator) and an index representing a logical connector must fail
with a return code of &#8220;No such indicator implemented&#8221;
(-3).</para>
</listitem>
</varlistentry>
</varlistentry>
</variablelist>
</section>

</section>

<section xml:id="sec_set_indicator">
<title><emphasis>set-indicator</emphasis> (dr-indicator)</title>
<para>Logical connectors do not have associated dr-indicators (token
value 9002). An attempt to set the state of such an indicator results in
a &#8220;No such indicator implemented&#8221; return status.
</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_set_indicator"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> The calling of
<emphasis>set-indicator</emphasis> with a token value of 9002
(dr-indicator) and an index representing a logical connector must fail
with a return code of &#8220;No such indicator implemented&#8221;
(-3).</para>
</listitem>
</varlistentry>
</variablelist>
</section>

<section xml:id="sec_ibm_configure_connnector">
<title><emphasis>ibm,configure-connector</emphasis></title>
<para>The
<emphasis>ibm,configure-connector</emphasis> RTAS call is used to return
to the OS the device tree nodes and properties associated with the newly
un-isolated logical resources and configure them for use.</para>
<para>The
<emphasis>ibm,configure-connector</emphasis> RTAS call used against a
logical DR connector can encounter other logical DR connectors or
physical DR connectors below it in the tree. If a logical connector is
encountered below a logical connector that is being configured, the
<emphasis>ibm,configure-connector</emphasis> RTAS call will not configure
the sub-tree, if it is not owned by the OS (where owned refers to a DR
connector that would return a DR entity usable, for a
<emphasis>get-sensor</emphasis> dr-entity-sense sensor). If a physical
connector is encountered, then the sub-tree below the physical connector
may or may not be configured, depending on the implementation.</para>
<para>
<emphasis role="bold">Architecture Note:</emphasis> The requirements of this section
specify the minimum sub-tree contents returned for various connector
types. Implementations may optionally return other valid previously
reported nodes that represent the current configuration of the device
tree. Previously reported nodes may not have any changes from their
previously reported state. A node that was removed from the configuration
due to a DR operation and returns due to a subsequent DR operation is not
considered to have been previously reported. It is the caller's
responsibility to recognize previously reported nodes.</para>
<section xml:id="sec_ibm_configure_connnector">
<title><emphasis>ibm,configure-connector</emphasis></title>
<para>The
<emphasis>ibm,configure-connector</emphasis> RTAS call is used to return
to the OS the device tree nodes and properties associated with the newly
un-isolated logical resources and configure them for use.</para>
<para>The
<emphasis>ibm,configure-connector</emphasis> RTAS call used against a
logical DR connector can encounter other logical DR connectors or
physical DR connectors below it in the tree. If a logical connector is
encountered below a logical connector that is being configured, the
<emphasis>ibm,configure-connector</emphasis> RTAS call will not configure
the sub-tree, if it is not owned by the OS (where owned refers to a DR
connector that would return a DR entity usable, for a
<emphasis>get-sensor</emphasis> dr-entity-sense sensor). If a physical
connector is encountered, then the sub-tree below the physical connector
may or may not be configured, depending on the implementation.</para>
<para>
<emphasis role="bold">Architecture Note:</emphasis> The requirements of this section
specify the minimum sub-tree contents returned for various connector
types. Implementations may optionally return other valid previously
reported nodes that represent the current configuration of the device
tree. Previously reported nodes may not have any changes from their
previously reported state. A node that was removed from the configuration
due to a DR operation and returns due to a subsequent DR operation is not
considered to have been previously reported. It is the caller's
responsibility to recognize previously reported nodes.</para>

<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector that is
isolated,
<emphasis>ibm,configure-connector</emphasis> must immediately return
configuration complete.</para>
</listitem>
</varlistentry>
<variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector that is
isolated,
<emphasis>ibm,configure-connector</emphasis> must immediately return
configuration complete.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If the connector index refers
to a connector that would return a &#8220;DR entity unusable&#8221;
status (2), &#8220;DR entity available for exchange&#8221; status (3), or
&#8220;DR entity available for recovery&#8221; status (4) to the
<emphasis>get-sensor</emphasis> dr-entity-sense token, the
<emphasis>ibm,configure-connector</emphasis> RTAS call must return
&#8220;-9003: Cannot configure - Logical DR connector unusable, available
for exchange, or available for recovery&#8221; on the first call without
any configuration action taken on the DR connector.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If the connector index refers
to a connector that would return a &#8220;DR entity unusable&#8221;
status (2), &#8220;DR entity available for exchange&#8221; status (3), or
&#8220;DR entity available for recovery&#8221; status (4) to the
<emphasis>get-sensor</emphasis> dr-entity-sense token, the
<emphasis>ibm,configure-connector</emphasis> RTAS call must return
&#8220;-9003: Cannot configure - Logical DR connector unusable, available
for exchange, or available for recovery&#8221; on the first call without
any configuration action taken on the DR connector.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector of type
CPU,
the returned sub-tree must consist of the specific
cpu-node, its children, and any referenced nodes that had not been
previously reported (such as L2 and L3 caches etc.) all containing the
properties as would be contained in those nodes had they been available
at boot time.</para>
<para>
<emphasis role="bold">Implementation Note:</emphasis> Future platforms that support
concurrent maintenance of caches, will require that high level cache
nodes (L2, L3 etc.) are added by
<emphasis>ibm,configure-connector</emphasis> such that their properties
can change as new/repaired hardware is added to the platform. Therefore,
it is the OS's responsibility when isolating a CPU to purge any
information it may have regarding an orphaned high level cache node. The
OS may use the
<emphasis role="bold"><literal>&#8220;ibm,phandle&#8221;</literal></emphasis> property to selectively
remove caches when a processor is removed. The platform considers any
high level cache that is newly referenced (reference count for this
partition goes from 0 to 1) to have been previously unreported.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector of type
CPU,
the returned sub-tree must consist of the specific
cpu-node, its children, and any referenced nodes that had not been
previously reported (such as L2 and L3 caches etc.) all containing the
properties as would be contained in those nodes had they been available
at boot time.</para>
<para>
<emphasis role="bold">Implementation Note:</emphasis> Future platforms that support
concurrent maintenance of caches, will require that high level cache
nodes (L2, L3 etc.) are added by
<emphasis>ibm,configure-connector</emphasis> such that their properties
can change as new/repaired hardware is added to the platform. Therefore,
it is the OS's responsibility when isolating a CPU to purge any
information it may have regarding an orphaned high level cache node. The
OS may use the
<emphasis role="bold"><literal>&#8220;ibm,phandle&#8221;</literal></emphasis> property to selectively
remove caches when a processor is removed. The platform considers any
high level cache that is newly referenced (reference count for this
partition goes from 0 to 1) to have been previously unreported.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis role="bold"><literal>ibm,configure-connector</literal></emphasis> specifies a connector of type
MEM,
the returned sub-tree must consist of the specific
<emphasis role="bold"><literal>ibm,memory-region</literal></emphasis> node containing the properties as
would be contained in that node had it been available at boot
time.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis role="bold"><literal>ibm,configure-connector</literal></emphasis> specifies a connector of type
MEM,
the returned sub-tree must consist of the specific
<emphasis role="bold"><literal>ibm,memory-region</literal></emphasis> node containing the properties as
would be contained in that node had it been available at boot
time.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector of type
PHB or SLOT, then all of the following must be true:
<orderedlist numeration="loweralpha">
<listitem>
<para>The returned values must represent the sub-tree for the specific
I/O sub-system represented by the connector, except for entities below
any DR connectors (logical or physical) which are below the connector
which is the target of the ibm,configure-connector operation (that is,
the ibm,configure-connector operation stops at any DR connector).</para>
</listitem>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector of type
PHB or SLOT, then all of the following must be true:
<orderedlist numeration="loweralpha">
<listitem>
<para>The returned values must represent the sub-tree for the specific
I/O sub-system represented by the connector, except for entities below
any DR connectors (logical or physical) which are below the connector
which is the target of the ibm,configure-connector operation (that is,
the ibm,configure-connector operation stops at any DR connector).</para>
</listitem>

<listitem>
<para>The sub-tree must consist of the specific node and its children
all containing the properties as would be contained in those nodes had
they been available at boot time, including (if they exist) built-in PCI
IOAs.</para>
</listitem>
</orderedlist>
</para>
</listitem>
</varlistentry>
<listitem>
<para>The sub-tree must consist of the specific node and its children
all containing the properties as would be contained in those nodes had
they been available at boot time, including (if they exist) built-in PCI
IOAs.</para>
</listitem>
</orderedlist>
</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector of type
SLOT,
the returned values must represent the sub-tree for
the specific I/O sub-system represented by the SLOT connector, and the
sub-tree must consist of the specific
<emphasis role="bold"><literal>/pci</literal></emphasis> node and its children all containing the
properties as would be contained in those nodes had they been available
at boot time, except for the PCI IOA nodes assigned to the OS image that
contain the same properties as they would following a PCI hot plug
operation (see
<xref linkend="dbdoclet.50569342_67543" />).</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector of type
SLOT,
the returned values must represent the sub-tree for
the specific I/O sub-system represented by the SLOT connector, and the
sub-tree must consist of the specific
<emphasis role="bold"><literal>/pci</literal></emphasis> node and its children all containing the
properties as would be contained in those nodes had they been available
at boot time, except for the PCI IOA nodes assigned to the OS image that
contain the same properties as they would following a PCI hot plug
operation (see
<xref linkend="dbdoclet.50569342_67543" />).</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a platform implementation
powers-up and configures physical DR entities in the sub-tree under a
logical DR connector, then a request to
<emphasis>ibm,configure-connector</emphasis> of the logical DR connector
must use the return status of 990x from the
<emphasis>ibm,configure-connector</emphasis> call, as necessary, during
the DR entity power-up sequence(s) and must control any power-up and
sequencing requirements, as would be done by the platform during platform
power-up.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a platform implementation
powers-up and configures physical DR entities in the sub-tree under a
logical DR connector, then a request to
<emphasis>ibm,configure-connector</emphasis> of the logical DR connector
must use the return status of 990x from the
<emphasis>ibm,configure-connector</emphasis> call, as necessary, during
the DR entity power-up sequence(s) and must control any power-up and
sequencing requirements, as would be done by the platform during platform
power-up.</para>
</listitem>
</varlistentry>

<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector of
type CO- PLATFAC or COPLATFUN, the returned values must represent the
sub-tree for the specific coherent plat- form sub-system represented by
the COPLATFAC or COPLATFUN connector. All properties are updated with
the most recent data from the coherent platform resource.</para>
</listitem>
</varlistentry>
</variablelist>
<varlistentry>
<term><emphasis role="bold">R1-<xref linkend="sec_ibm_configure_connnector"
xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
<listitem>
<para><emphasis role="bold">For all LRDR options:</emphasis> If a request to
<emphasis>ibm,configure-connector</emphasis> specifies a connector of
type CO- PLATFAC or COPLATFUN, the returned values must represent the
sub-tree for the specific coherent plat- form sub-system represented by
the COPLATFAC or COPLATFUN connector. All properties are updated with
the most recent data from the coherent platform resource.</para>
</listitem>
</varlistentry>
</variablelist>

</section>
</section>
</section>
</chapter>

0
Platform/ch_interrupt_controller.xml → LoPAR/ch_interrupt_controller.xml
Unescape Escape View File

0
Platform/ch_platform_intro.xml → LoPAR/ch_introduction.xml
Unescape Escape View File

0
Platform/ch_io_devices.xml → LoPAR/ch_io_devices.xml
Unescape Escape View File

0
Platform/ch_io_topology.xml → LoPAR/ch_io_topology.xml
Unescape Escape View File

0
Virtualization/ch_lpar_option.xml → LoPAR/ch_lpar_option.xml
Unescape Escape View File

0
Platform/ch_nonvolatile_memory.xml → LoPAR/ch_nonvolatile_memory.xml
Unescape Escape View File

17
Error Handling/ch_notifications.xml → LoPAR/ch_notifications.xml
Unescape Escape View File

@ -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,18 +13,19 @@
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.

-->
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0" xml:lang="en"
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0" xml:lang="en"
xml:id="dbdoclet.50569337_37595">

<title>Error and Event Notification</title>
<?dbhtml stop-chunking?>

<xi:include href="sec_error_introduction.xml"/>
<xi:include href="sec_error_reporting.xml"/>
<xi:include href="sec_rtas_error_classes.xml"/>
<xi:include href="sec_rtas_error_reporting.xml"/>
<xi:include href="sec_error_codes.xml"/>
</chapter>

0
Platform/ch_numa.xml → LoPAR/ch_numa.xml
Unescape Escape View File

0
Platform/ch_processors_memory.xml → LoPAR/ch_processors_memory.xml
Unescape Escape View File

314
Platform/ch_product_topology.xml → LoPAR/ch_product_topology.xml
Unescape Escape View File

@ -1594,177 +1594,177 @@ xml:lang="en">
</listitem>
</itemizedlist>
</section>
</section>

<section xml:id="sec_resource_location_codes">
<title>Resource Location Codes</title>

<para>The resource location label consists of the
prefix 'R' followed by a non-zero decimal number. A
resource location code identifies a chip or function
embedded on a FRU. There may be multiple
resources associated with a FRU. The numbering of the
resources on a particular FRU should match
the left to right, top to bottom positioning of the
resources on the FRU when the FRU is in a typical
service position.</para>

<para>It should be noted that embedded adapters with
internal ports existed prior to introduction of the
resource label. Use of the resource label for unique
partitionable endpoint identification may or may
not be retrofitted to those adapters as they are
carried forward to new platforms.</para>
</section>
<section xml:id="sec_resource_location_codes">
<title>Resource Location Codes</title>

<para>The resource location label consists of the
prefix 'R' followed by a non-zero decimal number. A
resource location code identifies a chip or function
embedded on a FRU. There may be multiple
resources associated with a FRU. The numbering of the
resources on a particular FRU should match
the left to right, top to bottom positioning of the
resources on the FRU when the FRU is in a typical
service position.</para>

<para>It should be noted that embedded adapters with
internal ports existed prior to introduction of the
resource label. Use of the resource label for unique
partitionable endpoint identification may or may
not be retrofitted to those adapters as they are
carried forward to new platforms.</para>
</section>

<section xml:id="sec_multiple_frus_same_physical_space">
<title>Multiple FRUs In The Same Physical Space</title>

<para>A physical location code is tied to the connector
that a FRU plugs into. If two different parts with
different part numbers can plug into the same connector,
both parts will have the same location code.
However, if two different parts can plug into two
different connectors but share the same physical
space when either is installed, those parts should
each have a different location code. For example, if
two different GX adapters (such as the Bjorn IB adapter
and Newcombe PCI slot riser on Jupiter-IOC)
connect to the same planar using the same connector,
they should both be assigned the same location
code. But if a GX adapter or a PCI adapter can be
installed on a planar, but not both at the same time
as they both can't fit at the same time given the
placement of the connectors on the planar, both slots
should be assigned unique location codes.</para>
</section>
<section xml:id="sec_multiple_frus_same_physical_space">
<title>Multiple FRUs In The Same Physical Space</title>

<para>A physical location code is tied to the connector
that a FRU plugs into. If two different parts with
different part numbers can plug into the same connector,
both parts will have the same location code.
However, if two different parts can plug into two
different connectors but share the same physical
space when either is installed, those parts should
each have a different location code. For example, if
two different GX adapters (such as the Bjorn IB adapter
and Newcombe PCI slot riser on Jupiter-IOC)
connect to the same planar using the same connector,
they should both be assigned the same location
code. But if a GX adapter or a PCI adapter can be
installed on a planar, but not both at the same time
as they both can't fit at the same time given the
placement of the connectors on the planar, both slots
should be assigned unique location codes.</para>
</section>

<section xml:id="sec_pcie_attached_io_drawers">
<title>PCI-E Attached I/O Drawers</title>

<para>A PCI-E attached I/O drawer is an I/O drawer that
attaches to a GX adapter in the CEC via PCI-E
cables (as opposed to RIO or IB cables). There are two
different types of PCI-E attached I/O drawers:
ones where PHB(s) on the GX adapter connect directly
to I/O devices in the drawer and ones where the
PHB(s) on the GX adapter connect to switches (or other
fan-out logic) in the I/O drawer. In the former
case, the partitionable endpoint (PE) is the logical
PHB connection to the device. In the latter case, the
PEs are the slots wired to the downstream switch ports.</para>

<para>For GX cards whose PHBs connect directly to
devices in the I/O drawer (such as Bluehawk), the
location code and DRC name of the I/O slot partitionable
endpoint will be of the form Ucec-Pw-Cx-
Ty-Lz. Here, Ucec is the type/model/serial of the CEC
that contains the GX adapter, Pw is the planar
that contains the GX adapter, Cx is the GX adapter,
Ty is one of the ports on the adapter, and Lz is a
logical label representing a logical PCI-e connection
to an I/O device at the other end of the PCI-e
cable plugged into that port (note that there may be
multiple Cx labels if the GX adapter doesn't plug
directly into the planar in the system in question).
This location code and DRC name will be generated
by system firmware for each PE on each GX adapter that
is installed in the system and that supports
direct-connect drawers (i.e. drawers without a PCI-E
switch in them). The location code and DRC
name will be generated regardless of whether or not a
PCI-E cable is attached to the GX adapter.
It is permissible to append additional labels beyond
the L label to create different location codes for
FRUs/devices downstream from the I/O device in the
drawer that is attached to the PCI-e cable. It is
not required that all subsequent labels be logical labels.</para>

<para>For GX cards whose ports connect to a PCI-E switch
in an I/O drawer via PCI-E cables, the location
code format has not yet been defined.</para>
</section>
<section xml:id="sec_pcie_attached_io_drawers">
<title>PCI-E Attached I/O Drawers</title>

<para>A PCI-E attached I/O drawer is an I/O drawer that
attaches to a GX adapter in the CEC via PCI-E
cables (as opposed to RIO or IB cables). There are two
different types of PCI-E attached I/O drawers:
ones where PHB(s) on the GX adapter connect directly
to I/O devices in the drawer and ones where the
PHB(s) on the GX adapter connect to switches (or other
fan-out logic) in the I/O drawer. In the former
case, the partitionable endpoint (PE) is the logical
PHB connection to the device. In the latter case, the
PEs are the slots wired to the downstream switch ports.</para>

<para>For GX cards whose PHBs connect directly to
devices in the I/O drawer (such as Bluehawk), the
location code and DRC name of the I/O slot partitionable
endpoint will be of the form Ucec-Pw-Cx-
Ty-Lz. Here, Ucec is the type/model/serial of the CEC
that contains the GX adapter, Pw is the planar
that contains the GX adapter, Cx is the GX adapter,
Ty is one of the ports on the adapter, and Lz is a
logical label representing a logical PCI-e connection
to an I/O device at the other end of the PCI-e
cable plugged into that port (note that there may be
multiple Cx labels if the GX adapter doesn't plug
directly into the planar in the system in question).
This location code and DRC name will be generated
by system firmware for each PE on each GX adapter that
is installed in the system and that supports
direct-connect drawers (i.e. drawers without a PCI-E
switch in them). The location code and DRC
name will be generated regardless of whether or not a
PCI-E cable is attached to the GX adapter.
It is permissible to append additional labels beyond
the L label to create different location codes for
FRUs/devices downstream from the I/O device in the
drawer that is attached to the PCI-e cable. It is
not required that all subsequent labels be logical labels.</para>

<para>For GX cards whose ports connect to a PCI-E switch
in an I/O drawer via PCI-E cables, the location
code format has not yet been defined.</para>
</section>

<section xml:id="sec_virtual_scsi_device_location_codes">
<title>Virtual SCSI (vSCSI) Device Location Codes</title>

<para>The location code for a virtual SCSI (vSCSI)
device is formed by appending an L label to the location
code of the parent virtual IOA. The L label contains a
48 or 64 bit hexadecimal value that uniquely
identifies the virtualized SCSI device. A virtual
SCSI device attached to a virtual IOA at
U9119.MME.1085B17-V4-C5-T1 would have a location code of the form:
U9119.MME.1085B17-V4-C5-T1-L8100000000000000
Note that some old pSeries firmware may represent
the virtualized device identifier as
W8100000000000000-L0 rather than simply L8100000000000000. This approach was abandoned in
late 2008.</para>

<para>See <xref linkend="dbdoclet.50569341_32742" /> for a description of the
virtual IOA location code.</para>
</section>
<section xml:id="sec_virtual_scsi_device_location_codes">
<title>Virtual SCSI (vSCSI) Device Location Codes</title>

<para>The location code for a virtual SCSI (vSCSI)
device is formed by appending an L label to the location
code of the parent virtual IOA. The L label contains a
48 or 64 bit hexadecimal value that uniquely
identifies the virtualized SCSI device. A virtual
SCSI device attached to a virtual IOA at
U9119.MME.1085B17-V4-C5-T1 would have a location code of the form:
U9119.MME.1085B17-V4-C5-T1-L8100000000000000
Note that some old pSeries firmware may represent
the virtualized device identifier as
W8100000000000000-L0 rather than simply L8100000000000000. This approach was abandoned in
late 2008.</para>

<para>See <xref linkend="dbdoclet.50569341_32742" /> for a description of the
virtual IOA location code.</para>
</section>

<section xml:id="sec_virtual_fibre_channel_device_location_codes">
<title>Virtual Fibre Channel Device Location Codes</title>
<section xml:id="sec_virtual_fibre_channel_device_location_codes">
<title>Virtual Fibre Channel Device Location Codes</title>

<para>The location code for a virtual fibre channel device
is formed by appending the worldwide unique port
identifier (W label) and LUN (L label) to the location
code of the parent virtual IOA. The values of
the L and W labels are both in hexadecimal. A fibre
channel disk attached to a virtual IOA at
U9119.MME.1085B17-V4-C5-T1 would have a location
code of the form:</para>
<para>The location code for a virtual fibre channel device
is formed by appending the worldwide unique port
identifier (W label) and LUN (L label) to the location
code of the parent virtual IOA. The values of
the L and W labels are both in hexadecimal. A fibre
channel disk attached to a virtual IOA at
U9119.MME.1085B17-V4-C5-T1 would have a location
code of the form:</para>

<itemizedlist mark="none">
<listitem>
<para>U9119.MME.1085B17-V2-C4-T1-W123456789ABCDEF0-L1A05000000000000</para>
</listitem>
</itemizedlist>
<itemizedlist mark="none">
<listitem>
<para>U9119.MME.1085B17-V2-C4-T1-W123456789ABCDEF0-L1A05000000000000</para>
</listitem>
</itemizedlist>

<para>See <xref linkend="dbdoclet.50569341_32742" /> for a description of the
virtual IOA location code.</para>
</section>
<para>See <xref linkend="dbdoclet.50569341_32742" /> for a description of the
virtual IOA location code.</para>
</section>

<section xml:id="sec_nvme_device_logical_path_location_codes">
<title>NVMe Device Logical Path Location Codes</title>
<section xml:id="sec_nvme_device_logical_path_location_codes">
<title>NVMe Device Logical Path Location Codes</title>

<para>Non-volatile memory (NVM) devices that are
not mounted/docked on a backplane that supports
location code VPD will have location codes composed
of the location code of the controlling IOA
followed by a L label. The number value of L label
is a decimal value, and it is the unique NVMe
namespace identifier. An NVMe device controlled by
an IOA at U787A.001.1012345-P1-C5 would
have a location code of the form:</para>
<para>Non-volatile memory (NVM) devices that are
not mounted/docked on a backplane that supports
location code VPD will have location codes composed
of the location code of the controlling IOA
followed by a L label. The number value of L label
is a decimal value, and it is the unique NVMe
namespace identifier. An NVMe device controlled by
an IOA at U787A.001.1012345-P1-C5 would
have a location code of the form:</para>

<itemizedlist mark="none">
<listitem>
<para>U787A.001.1012345-P1-C5-L3</para>
</listitem>
</itemizedlist>
</section>
<itemizedlist mark="none">
<listitem>
<para>U787A.001.1012345-P1-C5-L3</para>
</listitem>
</itemizedlist>
</section>

<section xml:id="sec_virtual_capi_function_location_codes">
<title>Virtual Coherent Accelerator (CAPI) Function Location Codes</title>
<section xml:id="sec_virtual_capi_function_location_codes">
<title>Virtual Coherent Accelerator (CAPI) Function Location Codes</title>

<para>The location code for a virtual coherent accelerator
(CA) function is formed by appending two S labels,
the first specifying the identifier of the physical
function and the second specifying the identifier of the
logical function, both in decimal, to the location code of
the physical CAPI adapter. A virtual CA
function associated with physical function 1 and logical
function 2 on the CAPI adapter at location
U78CA.001.1234567-P1-C4-C1 would have location code:</para>
<para>The location code for a virtual coherent accelerator
(CA) function is formed by appending two S labels,
the first specifying the identifier of the physical
function and the second specifying the identifier of the
logical function, both in decimal, to the location code of
the physical CAPI adapter. A virtual CA
function associated with physical function 1 and logical
function 2 on the CAPI adapter at location
U78CA.001.1234567-P1-C4-C1 would have location code:</para>

<itemizedlist mark="none">
<listitem>
<para>U78CA.001.1234567-P1-C4-C1-S1-S2</para>
</listitem>
</itemizedlist>
<itemizedlist mark="none">
<listitem>
<para>U78CA.001.1234567-P1-C4-C1-S1-S2</para>
</listitem>
</itemizedlist>
</section>
</section>
</section>

30
LoPAR/ch_rtas.xml
Unescape Escape View File

@ -0,0 +1,30 @@
<?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

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
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.

-->
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xl="http://www.w3.org/1999/xlink"
version="5.0" xml:lang="en">

<title>Run-Time Abstration Services</title>
<?dbhtml stop-chunking?>

<xi:include href="sec_rtas_introduction.xml"/>
<xi:include href="sec_rtas_environment.xml"/>
<xi:include href="sec_rtas_call_defn.xml"/>

</chapter>

1734
Error Handling/app_service_indicators.xml → LoPAR/ch_service_indicators.xml
View File

File diff suppressed because it is too large Load Diff

0
Platform/ch_smp.xml → LoPAR/ch_smp.xml
Unescape Escape View File

0
Platform/ch_system_reqs.xml → LoPAR/ch_system_reqs.xml
Unescape Escape View File

0
Virtualization/ch_virtual_io.xml → LoPAR/ch_virtual_io.xml
Unescape Escape View File

0
Platform/figures/PAPR-10.gif → LoPAR/figures/PAPR-10.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 66 KiB

After

Width:  |  Height:  |  Size: 66 KiB

0
Platform/figures/PAPR-11.gif → LoPAR/figures/PAPR-11.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 133 KiB

After

Width:  |  Height:  |  Size: 133 KiB

0
Platform/figures/PAPR-12.gif → LoPAR/figures/PAPR-12.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 65 KiB

After

Width:  |  Height:  |  Size: 65 KiB

0
Platform/figures/PAPR-14.gif → LoPAR/figures/PAPR-14.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 64 KiB

After

Width:  |  Height:  |  Size: 64 KiB

0
Platform/figures/PAPR-15.gif → LoPAR/figures/PAPR-15.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

0
Virtualization/figures/PAPR-18.gif → LoPAR/figures/PAPR-18.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

0
Virtualization/figures/PAPR-19.gif → LoPAR/figures/PAPR-19.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 57 KiB

After

Width:  |  Height:  |  Size: 57 KiB

0
Virtualization/figures/PAPR-20.gif → LoPAR/figures/PAPR-20.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 38 KiB

After

Width:  |  Height:  |  Size: 38 KiB

0
Virtualization/figures/PAPR-22.gif → LoPAR/figures/PAPR-22.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.9 KiB

After

Width:  |  Height:  |  Size: 2.9 KiB

0
Virtualization/figures/PAPR-23.gif → LoPAR/figures/PAPR-23.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.8 KiB

After

Width:  |  Height:  |  Size: 3.8 KiB

0
Virtualization/figures/PAPR-24.gif → LoPAR/figures/PAPR-24.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 7.0 KiB

After

Width:  |  Height:  |  Size: 7.0 KiB

0
Virtualization/figures/PAPR-25.gif → LoPAR/figures/PAPR-25.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 2.8 KiB

After

Width:  |  Height:  |  Size: 2.8 KiB

0
Virtualization/figures/PAPR-26.gif → LoPAR/figures/PAPR-26.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.8 KiB

After

Width:  |  Height:  |  Size: 3.8 KiB

0
Virtualization/figures/PAPR-27.gif → LoPAR/figures/PAPR-27.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.8 KiB

After

Width:  |  Height:  |  Size: 3.8 KiB

0
Virtualization/figures/PAPR-28.gif → LoPAR/figures/PAPR-28.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.6 KiB

After

Width:  |  Height:  |  Size: 3.6 KiB

0
Virtualization/figures/PAPR-29.gif → LoPAR/figures/PAPR-29.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

0
Virtualization/figures/PAPR-29_t0_31.gif → LoPAR/figures/PAPR-29_t0_31.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 29 KiB

After

Width:  |  Height:  |  Size: 29 KiB

0
Platform/figures/PAPR-3.gif → LoPAR/figures/PAPR-3.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

0
Virtualization/figures/PAPR-30.gif → LoPAR/figures/PAPR-30.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 8.7 KiB

After

Width:  |  Height:  |  Size: 8.7 KiB

0
Virtualization/figures/PAPR-31.gif → LoPAR/figures/PAPR-31.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 9.2 KiB

After

Width:  |  Height:  |  Size: 9.2 KiB

0
Platform/figures/PAPR-32.gif → LoPAR/figures/PAPR-32.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 31 KiB

0
Virtualization/figures/PAPR-33.gif → LoPAR/figures/PAPR-33.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 26 KiB

0
Error Handling/figures/PAPR-34.gif → LoPAR/figures/PAPR-34.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 50 KiB

After

Width:  |  Height:  |  Size: 50 KiB

0
Error Handling/figures/PAPR-36.gif → LoPAR/figures/PAPR-36.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 46 KiB

0
Error Handling/figures/PAPR-37.gif → LoPAR/figures/PAPR-37.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 36 KiB

0
Error Handling/figures/PAPR-38.gif → LoPAR/figures/PAPR-38.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.1 KiB

After

Width:  |  Height:  |  Size: 1.1 KiB

0
Error Handling/figures/PAPR-39.gif → LoPAR/figures/PAPR-39.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1012 B

After

Width:  |  Height:  |  Size: 1012 B

0
Platform/figures/PAPR-4.gif → LoPAR/figures/PAPR-4.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 17 KiB

After

Width:  |  Height:  |  Size: 17 KiB

0
Error Handling/figures/PAPR-40.gif → LoPAR/figures/PAPR-40.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.1 KiB

After

Width:  |  Height:  |  Size: 1.1 KiB

0
Error Handling/figures/PAPR-41.gif → LoPAR/figures/PAPR-41.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 47 KiB

After

Width:  |  Height:  |  Size: 47 KiB

0
Error Handling/figures/PAPR-42.gif → LoPAR/figures/PAPR-42.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

0
Error Handling/figures/PAPR-43.gif → LoPAR/figures/PAPR-43.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 24 KiB

0
Error Handling/figures/PAPR-44.gif → LoPAR/figures/PAPR-44.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 46 KiB

After

Width:  |  Height:  |  Size: 46 KiB

0
Error Handling/figures/PAPR-45.gif → LoPAR/figures/PAPR-45.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

0
Error Handling/figures/PAPR-46.gif → LoPAR/figures/PAPR-46.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

0
Error Handling/figures/PAPR-47.gif → LoPAR/figures/PAPR-47.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

0
Error Handling/figures/PAPR-48.gif → LoPAR/figures/PAPR-48.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 55 KiB

After

Width:  |  Height:  |  Size: 55 KiB

0
Error Handling/figures/PAPR-49.gif → LoPAR/figures/PAPR-49.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

0
Error Handling/figures/PAPR-50.gif → LoPAR/figures/PAPR-50.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

0
Error Handling/figures/PAPR-51.gif → LoPAR/figures/PAPR-51.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 9.8 KiB

After

Width:  |  Height:  |  Size: 9.8 KiB

0
Error Handling/figures/PAPR-52.gif → LoPAR/figures/PAPR-52.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

0
Error Handling/figures/PAPR-53.gif → LoPAR/figures/PAPR-53.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

0
Error Handling/figures/PAPR-54.gif → LoPAR/figures/PAPR-54.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 9.7 KiB

After

Width:  |  Height:  |  Size: 9.7 KiB

0
Virtualization/figures/PAPR-55.gif → LoPAR/figures/PAPR-55.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 39 KiB

After

Width:  |  Height:  |  Size: 39 KiB

0
Virtualization/figures/PAPR-58.gif → LoPAR/figures/PAPR-58.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 51 KiB

After

Width:  |  Height:  |  Size: 51 KiB

0
Virtualization/figures/PAPR-59.gif → LoPAR/figures/PAPR-59.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 37 KiB

After

Width:  |  Height:  |  Size: 37 KiB

0
Platform/figures/PAPR-6.gif → LoPAR/figures/PAPR-6.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 30 KiB

0
DeviceTree/figures/PAPR-60.gif → LoPAR/figures/PAPR-60.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 36 KiB

After

Width:  |  Height:  |  Size: 36 KiB

0
DeviceTree/figures/PAPR-61.gif → LoPAR/figures/PAPR-61.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 7.1 KiB

After

Width:  |  Height:  |  Size: 7.1 KiB

0
DeviceTree/figures/PAPR-62.gif → LoPAR/figures/PAPR-62.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 24 KiB

0
DeviceTree/figures/PAPR-64.gif → LoPAR/figures/PAPR-64.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

0
Virtualization/figures/PAPR-66.gif → LoPAR/figures/PAPR-66.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 19 KiB

0
Virtualization/figures/PAPR-68.gif → LoPAR/figures/PAPR-68.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

0
Platform/figures/PAPR-7.gif → LoPAR/figures/PAPR-7.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 30 KiB

0
Virtualization/figures/PAPR-70.gif → LoPAR/figures/PAPR-70.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

0
Virtualization/figures/PAPR-71.gif → LoPAR/figures/PAPR-71.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 6.8 KiB

After

Width:  |  Height:  |  Size: 6.8 KiB

0
Virtualization/figures/PAPR-72.gif → LoPAR/figures/PAPR-72.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 5.3 KiB

After

Width:  |  Height:  |  Size: 5.3 KiB

0
Error Handling/figures/PAPR-73.gif → LoPAR/figures/PAPR-73.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 35 KiB

After

Width:  |  Height:  |  Size: 35 KiB

0
Platform/figures/PAPR-8.gif → LoPAR/figures/PAPR-8.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 56 KiB

After

Width:  |  Height:  |  Size: 56 KiB

0
Virtualization/figures/figure_format_vasi_add_buffer_crq_elem.gif → LoPAR/figures/figure_format_vasi_add_buffer_crq_elem.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

0
Virtualization/figures/figure_format_vasi_add_buffer_indirect_crq_elem.gif → LoPAR/figures/figure_format_vasi_add_buffer_indirect_crq_elem.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 32 KiB

0
Virtualization/figures/figure_format_vasi_close_crq_elem.gif → LoPAR/figures/figure_format_vasi_close_crq_elem.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 20 KiB

0
Virtualization/figures/figure_format_vasi_download_crq_elem.gif → LoPAR/figures/figure_format_vasi_download_crq_elem.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 24 KiB

0
Virtualization/figures/figure_format_vasi_exchange_cap_crq_elem.gif → LoPAR/figures/figure_format_vasi_exchange_cap_crq_elem.gif
Unescape Escape View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 24 KiB

Some files were not shown because too many files have changed in this diff Show More

Write Preview
Loading…
Cancel
Save