<?xml version="1.0"?>
<chapter xmlns="http://docbook.org/ns/docbook" 
xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en">
  <title>I/O Devices</title>

  <para>This chapter describes requirements for IOAs. It adds detail to areas 
  of the PCI architectures (conventional PCI, PCI-X and PCI Express) that are 
  either unaddressed or optional. It also places some requirements on firmware 
  and the OS for IOA support. It provides references to specifications to which 
  IOAs must comply and gives design notes for IOAs that run on LoPAR systems. 
  </para>
  
  <section xml:id="sec_pci_ioas">
    <title>PCI IOAs</title>


    <variablelist>
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_pci_ioas" 
        xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
          <listitem>
            <para>All PCI IOAs must be capable of decoding and 
            generating either a full 32-bit address or a full 64-bit address.</para>
          </listitem>
     	</varlistentry>
     	
     	<varlistentry xml:id="dbdoclet.50569335_14547">
        <term><emphasis role="bold">R1-<xref linkend="sec_pci_ioas" 
        xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
          <listitem>
            <para>IOAs that implement conventional PCI must be compliant with the 
            most recent version of the <xref linkend="dbdoclet.50569387_65468"/> at the 
            time of their design, including any approved Engineering Change Requests (ECRs) 
            against that document. </para>
          </listitem>
     	</varlistentry>

     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_pci_ioas" 
        xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
          <listitem>
            <para>IOAs that implement PCI-X must be compliant 
            with the most recent version of the <xref linkend="dbdoclet.50569387_26550"/> 
            at the time of their design, including any approved Engineering Change Requests 
            (ECRs) against that document. </para>
          </listitem>
     	</varlistentry>

     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_pci_ioas" 
        xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
          <listitem>
            <para>IOAs that implement PCI Express must be 
            compliant with the most recent version of the <xref 
            linkend="dbdoclet.50569387_66784"/> at the time of their design, including any 
            approved Engineering Change Requests (ECRs) against that document</para>
          </listitem>
     	</varlistentry>
    </variablelist>

    <para><emphasis role="bold">Architecture Note:</emphasis> Revision 2.1 and later of 
    the <emphasis>PCI Local Bus Specification</emphasis> requires that PCI masters 
    which receive a Retry target termination to unconditionally repeat the same 
    request until it completes. The master may perform other bus transactions, but 
    cannot require those to complete before repeating the original transaction 
    which was previously target terminated with Retry. Revision 2.1 of the 
    specification (page 49) also includes an example which describes how the 
    requirement above applies to a multi-function IOA. See page 48-49 of the 2.1 
    revision of the <emphasis>PCI Local Bus Specification</emphasis> for more 
    detail. Revision 2.0 of the <emphasis>PCI Local Bus Specification</emphasis> 
    includes a definition of target termination via Retry, but did not spell out 
    the requirement described above for masters, as does the 2.1 revision of the 
    specification. Masters which are designed based on revision 2.0 of the 
    specification that perform other transactions following target termination with 
    Retry, may cause live-locks and/or deadlocks when installed in a system that 
    utilizes bridges (host bridge or PCI-PCI bridges) that implement Retry, delayed 
    transactions, and/or TCEs, when those masters require following transactions to 
    complete before the original transaction that was terminated with the target 
    Retry. This revision 2.0 to revision 2.1 compatibility problem has been 
    observed on several IOAs that have asked for deviations to Requirement <xref 
    linkend="dbdoclet.50569335_14547"/>. Wording was added to the revision 2.2 of 
    the <emphasis>PCI Local Bus Specification</emphasis> which makes a statement 
    similar to this Architecture Note.</para>
    
    <section xml:id="dbdoclet.50569335_36981">
      <title>Resource Locking</title>

      <variablelist>
       	<varlistentry xml:id="dbdoclet.50569335_16015">
          <term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569335_36981" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>PCI IOAs, excepting bridges, must not depend on the PCI LOCK# 
              signal for correct operation nor require any other PCI IOA to assert LOCK# for 
              correct operation.</para>
            </listitem>
       	</varlistentry>
      </variablelist>

      <para>There are some legacy IOAs on legacy buses which require LOCK#. 
      Additionally, LOCK# is used in some implementations to resolve deadlocks 
      between bridges under a single PHB. These uses of LOCK# are permitted. </para>
    </section>

    <section xml:id="dbdoclet.50569335_12219">
      <title>PCI Expansion ROMs</title>

      <variablelist>
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569335_12219" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>PCI expansion ROMs must have a ROM image 
              with a code type of 1 for OF as provided in the <xref 
              linkend="dbdoclet.50569387_65468"/>. This ROM image must abide by the ROM image 
              format for OF as documented in the <xref 
              linkend="dbdoclet.50569387_22451"/>.</para>
            </listitem>
       	</varlistentry>
      </variablelist>

      <para>LoPAR systems rely on OF - not BIOS - to boot. This is why strong 
      requirements for OF device support are made.</para>
      <para>Vital Product Data (VPD) is an optional feature for PCI adapters 
      and it is strongly recommended that VPD be included in all PCI expansion ROMs. 
      If it is put in the PCI expansion ROM in accordance with the <xref 
      linkend="dbdoclet.50569387_65468"/>, VPD will be reported in the OF device 
      tree. If the VPD information is formatted as defined in Revision 2.2 with the 
      new capabilities feature, or in any other format, firmware will not read the 
      VPD, and the device driver for the IOA will have to reformat any provided VPD 
      into an OS specified format. It is still required that the keywords and their 
      values must conform to those specified by either PCI 2.1 or PCI 2.2, no matter 
      how they are formatted. Refer to Requirement <xref 
      linkend="dbdoclet.50569341_65980"/>. </para>
    </section>

    <section xml:id="dbdoclet.50569335_35146">
      <title>Assignment of Interrupts to PCI IOAs</title>

      <variablelist>
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569335_35146" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>All PCI IOAs must use the PowerPC 
              interrupt controller, except when made transparent to the OS by the platform 
              through the architected hcall()s. </para>
            </listitem>
       	</varlistentry>
       	
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569335_35146" 
          xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
            <listitem>
              <para>PCI IOAs that do not reside in the 
              Peripheral Memory Space and Peripheral I/O Space of the same PHB must not share 
              the same LSI source.</para>
            </listitem>
       	</varlistentry>
      </variablelist>
      <para>For further information on the interrupt controller refer to <xref 
      linkend="dbdoclet.50569331_37856"/>. </para>
      <para>It is strongly advised that system board designers assign one 
      interrupt for each interrupt source. Additionally, multi-function PCI IOAs 
      should have multiple interrupt sources. For restrictions on sharing interrupts 
      with the LPAR option, see Requirement <xref linkend="LoPAR.Virtualization"/>. 
      For restrictions on sharing MSIs, see Requirement <xref 
      linkend="dbdoclet.50569331_84312"/> and Requirement <xref 
      linkend="dbdoclet.50569331_63544"/>.</para>
    </section>

    <section xml:id="sec_pci_bridges">
      <title>PCI-PCI Bridge Devices</title>

      <variablelist>
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="sec_pci_bridges" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>Firmware must initialize all PCI-to-PCI 
              bridges. See <xref linkend="dbdoclet.50569387_22451"/>.</para>
            </listitem>
       	</varlistentry>
      </variablelist>
      <para>All bridges and switches are required to comply with the bus 
      specification(s) of the buses to which they are attached. See Requirement <xref 
      linkend="dbdoclet.50569330_95825"/>.</para>
    </section>

    <section xml:id="sec_graphics">
      <title>Graphics Controller and Monitor Requirements for Clients</title>
      
      <para>The graphics requirements for servers are different from those for 
      portable and personal systems. </para>

      <variablelist>
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="sec_graphics" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>Plug-in graphics controllers for portable 
              and personal platforms must provide graphics mode sets in the OF PCI expansion 
              ROM image in accordance with the
              <xref linkend="dbdoclet.50569387_22451"/>.</para>
            </listitem>
       	</varlistentry>
      </variablelist>

      <para>Portable and personal platforms are strongly urged to support some 
      mechanism which allows the platform to electronically sense the display 
      capabilities of monitors. </para>

      <para>For graphics controllers that are placed on the system board, the 
      graphics mode sets can be put in system ROM. The mode set software put in the 
      system ROM in this case would be FCode and would be largely or entirely the 
      same as the FCode that would be in the PCI expansion ROM if the same graphics 
      controller was put on a plug-in PCI card.</para>
    </section>

    <section xml:id="dbdoclet.50569335_21614">
      <title>PCI Plug-in Graphic Cards</title>

      <variablelist>
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569335_21614" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para><emphasis>(Requirement Number Reserved 
              For Compatibility)</emphasis></para>
            </listitem>
       	</varlistentry>
       	
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="dbdoclet.50569335_21614" 
          xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
            <listitem>
              <para>PCI plug-in graphics cards which are 
              going to be the primary display IOA during the time prior to the OS device 
              driver being loaded must contain an OF display driver on the IOA.</para>
            </listitem>
       	</varlistentry>
      </variablelist>
    </section>
    
    <section xml:id="sec_pci_cache">
      <title>PCI Cache Support Protocol</title>
      <para>The PCI architecture allows for the optional implementation of 
      caching of data. This architecture basically assumes that the data in I/O 
      memory is non-coherent. As such, platforms are not required to implement the 
      optional PCI Cache Support protocol using the SBO# and SDONE signals. 
      Therefore, IOAs used in LoPAR platforms should not count on those signals for 
      proper operations.</para>

      <variablelist>
       	<varlistentry xml:id="dbdoclet.50569335_39614">
          <term><emphasis role="bold">R1-<xref linkend="sec_pci_cache" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>IOAs used in LoPAR platforms 
              and their device drivers must not require the use of the PCI signals SBO# and 
              SDONE for proper operations. </para>
            </listitem>
       	</varlistentry>
      </variablelist>
    </section>

    <section xml:id="sec_pci_config_space">
      <title>PCI Configuration Space for IOAs</title>
      <para>There are several writable fields in the PCI Configuration Header. 
      Some of these are written by the firmware and should never be changed by the 
      device driver. </para>

      <variablelist>
       	<varlistentry xml:id="dbdoclet.50569335_13568">
          <term><emphasis role="bold">R1-<xref linkend="sec_pci_config_space" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>All registers and bits in the PCI Configuration Header must be 
              set to a platform specific value by firmware and preserved by software, except 
              that software is responsible for setting the configuration space as indicated 
              in <xref linkend="dbdoclet.50569335_27772"/>.</para>

              <table frame="all" pgwide="1" xml:id="dbdoclet.50569335_27772">
                <title>Software Programming of PCI Configuration Header Registers</title>
                <tgroup cols="3">
                  <colspec colname="c1" colwidth="20*" align="center"/>
                  <colspec colname="c2" colwidth="20*" align="center"/>
                  <colspec colname="c3" colwidth="60*"/>
                  <thead>
                    <row>
                      <entry>
                        <para> Register Name</para>
                      </entry>
                      <entry>
                        <para> Bit Name</para>
                      </entry>
                      <entry align="center">
                        <para> Software Action</para>
                      </entry>
                    </row>
                  </thead>
                  <tbody>
                    <row>
                      <entry morerows="3">
                        <para> Command</para>
                      </entry>
                      <entry>
                        <para> Bus Master</para>
                      </entry>
                      <entry>
                        <para> Must write to a 1 before the first DMA operation after a 
                        reset. Must write to a 0 before unconfiguring device driver.</para>
                      </entry>
                    </row>
                    <row>
                      <entry>
                        <para> Memory Space</para>
                      </entry>
                      <entry>
                        <para> Must write to a 1 before the first MMIO operation to 
                        IOA&#x2019;s memory space (if any) after a reset. Must write to a 0 before 
                        unconfiguring device driver.</para>
                      </entry>
                    </row>
                    <row>
                      <entry>
                        <para> IO Space</para>
                      </entry>
                      <entry>
                        <para> Must write to a 1 before the first MMIO operation to 
                        IOA&#x2019;s I/O space (if any) after a reset. Must write to a 0 before 
                        unconfiguring device driver.</para>
                      </entry>
                    </row>
                    <row>
                      <entry>
                        <para> all other bits</para>
                      </entry>
                      <entry>
                        <para> Must restore to previous value after any reset operation 
                        (for example, via <emphasis>ibm,set-slot-reset Function</emphasis> 1 or 3). 
                        The <emphasis>ibm,configure-bridge</emphasis> RTAS call is available to assist 
                        in restoring values, where appropriate.</para>
                      </entry>
                    </row>
                    <row>
                      <entry>
                        <para>  Built in Self Test (BIST)</para>
                      </entry>
                      <entry>
                        <para> all</para>
                      </entry>
                      <entry>
                        <para> If implemented, software may use if desired.</para>
                      </entry>
                    </row>
                    <row>
                      <entry>
                        <para> all other PCI header registers that may be modified by 
                        firmware after initial reset or by <emphasis>ibm,configure-connector</emphasis> for DR operations</para>
                      </entry>
                      <entry>
                        <para> all</para>
                      </entry>
                      <entry>
                        <para> Must restore to previous value after any reset operation 
                        (for example, via <emphasis>ibm,set-slot-reset-state Function</emphasis> 1). 
                        The <emphasis>ibm,configure-bridge</emphasis> RTAS call is available to assist 
                        in configuring PCI bridges and switches, where appropriate.</para>
                      </entry>
                    </row>
                  </tbody>
                </tgroup>
              </table>
            </listitem>
       	</varlistentry>
       	
       	<varlistentry xml:id="dbdoclet.50569335_17839">
          <term><emphasis role="bold">R1-<xref linkend="sec_pci_config_space" 
          xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
            <listitem>
              <para>All IOAs that implement PCI-X Mode 2 or PCI Express must supply 
              the <emphasis role="bold"><literal>&#x201C;ibm,pci-config-space-type&#x201D;</literal></emphasis> property 
              (see <xref linkend="LoPAR.RTAS"/>).</para>
              <para><emphasis role="bold">Implementation Note:</emphasis> The 
              <emphasis role="bold"><literal>&#x201C;ibm,pci-config-space-type&#x201D;</literal></emphasis> 
              property in Requirement <xref linkend="dbdoclet.50569335_17839"/> is added for platforms that support 
              I/O fabric and IOAs that implement PCI-X Mode 2, and PCI Express. To access the 
              extended configuration space provided by PCI-X Mode 2 and PCI Express, all I/O 
              fabric leading up to an IOA must support a 12-bit register number. In other 
              words, if a platform implementation has a conventional PCI bridge leading up to 
              an IOA that implements PCI-X Mode 2, the platform will not be able to provide 
              access to the extended configuration space of that IOA. The 
              <emphasis role="bold"><literal>&#x201C;ibm,config-space-type&#x201D;</literal></emphasis> property in the IOA's OF node 
              is used by device drivers to determine if an IOA&#x2019;s extended 
              configuration space can be accessed. </para>
            </listitem>
       	</varlistentry>
      </variablelist>
    </section>

    <section xml:id="sec_ioa_bus_memory_space">
      <title>PCI IOA Use of PCI Bus Memory Space Address 0</title>
      <para>Some PCI IOAs will fail when given a bus address of 0. In the PC 
      world, address 0 would not be a good address, so some PCI IOA designs which 
      were designed for the PC arena will check for an address of 0, and fail the 
      operation if it is 0. </para>

      <variablelist>
       	<varlistentry xml:id="dbdoclet.50569335_30300">
          <term><emphasis role="bold">R1-<xref linkend="sec_ioa_bus_memory_space" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>For systems that use PCI IOAs 
              which will fail when given a bus address of 0 for DMA operations, and when the 
              operations for which those IOAs are used are other than system memory dump 
              operations, then the OS must prevent the mapping of PCI bus address 0 for PCI 
              DMA operation for such IOAs.</para>
            </listitem>
       	</varlistentry>
       	
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="sec_ioa_bus_memory_space" 
          xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
            <listitem>
              <para>PCI IOAs used for dumping contents of 
              system memory must operate properly with a PCI bus address of 0 for PCI DMA 
              operations.</para>
            </listitem>
       	</varlistentry>
       	
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="sec_ioa_bus_memory_space" 
          xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
            <listitem>
              <para>The firmware must not map an IOA used for 
              loading a boot image to an address of 0, when loading a boot image, if that IOA 
              cannot accept an address of 0.</para>
            </listitem>
       	</varlistentry>
      </variablelist>
      <para><emphasis role="bold">Implementation Note:</emphasis> A reasonable 
      implementation of Requirement <xref linkend="dbdoclet.50569335_30300"/> would 
      be to have an interface between the device driver and the kernel to allow the 
      device driver to indicate to the kernel that the restriction is required for 
      that IOA, so that all IOAs for that kernel image are not affected.</para>
    </section>

    <section xml:id="sec_pcie_comp_timeout">
      <title>PCI Express Completion Timeout</title>
      <para>Prior to the implementation of the PCI Express additional 
      capability to set the Completion Timeout Value and Completion Timeout Disable 
      in the PCI Express Device Control 2 register of an IOA, the IOAs need 
      device-specific way to provide the disable capability. In addition, the 
      platforms need to provide a way for the OSs and device drivers to know when to 
      disable the completion timeout of these devices that only provide a 
      device-specific way of doing so.</para>

      <variablelist>
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="sec_pcie_comp_timeout" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>PCI Express IOAs must either provide a 
              device-specific way to disable their DMA Completion Timeout timer or must 
              provide the Completion Timeout Disable or Completion Timeout Value capability 
              in the PCI Express Device Control 2 register, and device drivers for IOAs that 
              provide a device-specific way must disable their DMA Completion Timeout timer 
              if it is either unknown whether the IOA provides a sufficiently long timer 
              value for the platform, or if it is known that they do not provide a sufficient 
              timeout value (for example, if the 
              <emphasis role="bold"><literal>&#x201C;ibm,max-completion-latency&#x201D;</literal></emphasis> property is not 
              provided).</para>
            </listitem>
       	</varlistentry>
       	
       	<varlistentry xml:id="dbdoclet.50569335_65475">
          <term><emphasis role="bold">R1-<xref linkend="sec_pcie_comp_timeout" 
          xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
            <listitem>
              <para>Platforms must provide the 
              <emphasis role="bold"><literal>&#x201C;ibm,max-completion-latency&#x201D;</literal></emphasis> property in 
              each PCI Express PHB node of the OF Device Tree.</para>
            </listitem>
       	</varlistentry>
      </variablelist>

    </section>

    <section xml:id="sec_pcie_iov">
      <title>PCI Express I/O Virtualized (IOV) Adapters</title>
      <para>PCI Express defines I/O Virtualized (IOV) adapters, where such an 
      adapter has separate resources for each virtual instance, called a Virtual 
      Function (VF). There are two PCI specifications that exist to define such 
      adapters:</para>

      <itemizedlist>		      
        <listitem>
          <para><xref linkend="dbdoclet.50569387_94229"/> defines the 
          requirements for SR-IOV adapters.</para>
        </listitem>
        
        <listitem>
          <para><xref linkend="dbdoclet.50569387_42471"/> defines the 
          requirements for MR-IOV adapters.</para>
        </listitem>
      </itemizedlist>

      <para>The interface presented to an OS from an MR-IOV adapter will look 
      the same as an SR-IOV adapters, and therefore will not be described separately 
      here.</para>
      <para>IOV adapters and/or the VFs of an IOV adapter that has IOV enabled, 
      are assigned to OSs as follows (see also <xref 
      linkend="dbdoclet.50569335_70133"/> for a full set of characteristics of these 
      environments):</para>
        
      <itemizedlist>		      
        <listitem>
          <para>For the <emphasis>Legacy Dedicated</emphasis> environment, the 
          entire adapter is assigned to one LPAR, with the IOV functionality not enabled. 
          In this mode, the OS provides device driver(s) for the adapter Function(s). VFs 
          do not exist, because IOV is not enabled. The OS is given the capability to do 
          Hot Plug add, remove, and replace in a non-managed environment (without an 
          HMC), and may be given that capability in a managed environment. </para>
        </listitem>
        
        <listitem>
          <para>For the <emphasis>SR-IOV Non-shared</emphasis> environment, the 
          entire adapter is assigned to one LPAR, with IOV functionality enabled, but 
          with the Physical Function(s) (PFs) of the adapter hosted by the platform. Only 
          VFs are presented to the OS. The OS is given the capability to do Hot Plug add, 
          remove, and replace in a non-managed environment (without an HMC), and may be 
          given that capability in a managed environment. </para>
        </listitem>
        
        <listitem>
          <para>For the <emphasis>SR-IOV Shared</emphasis> environment, the 
          adapter is assigned to the platform, with IOV functionality enabled. The 
          platform then assigns VF(s) to OS(s). Only the managed environment applies, and 
          add/remove/replace operations are controlled by DLPAR operations to the OS(s) 
          from the management console.</para>
        </listitem>
      </itemizedlist>		      

      <para>For all environments except the SR-IOV Shared, multiple functions 
      will appear as a multi-function IOA with possible sharing of a single PE. For 
      example, the multi-function adapters may have a shared EEH domain and shared 
      DMA window.</para>
      <para>Determination of which of the above environments is supported for a 
      given platform and partition or OS type is beyond the scope of this 
      architecture.</para>
      <para><xref linkend="dbdoclet.50569335_70133"/> defines the 
      characteristics of these environments.</para>

      <table frame="all" pgwide="1" xml:id="dbdoclet.50569335_70133">
        <title>IOV Environment Characteristics </title>
        <tgroup cols="4">
          <colspec colname="c1" colwidth="55*"/>
          <colspec colname="c2" colwidth="15*" align="center"/>
          <colspec colname="c3" colwidth="15*" align="center"/>
          <colspec colname="c4" colwidth="15*" align="center"/>
          <thead>
            <row>
              <entry>
                <para>
                  <emphasis role="bold">&#xA0;</emphasis>
                </para>
              </entry>
              <entry>
                <para>
                  <emphasis role="bold">Legacy Dedicated</emphasis>
                </para>
              </entry>
              <entry>
                <para>
                  <emphasis role="bold">SR-IOV Non-shared</emphasis>
                </para>
              </entry>
              <entry>
                <para>
                  <emphasis role="bold">SR-IOV Shared</emphasis>
                </para>
              </entry>
            </row>
          </thead>
          <tbody>
            <row>
              <entry>
                <para>Entire adapter assigned to OS, IOV not enabled</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>n/a</para>
              </entry>
              <entry>
                <para>n/a</para>
              </entry>
            </row>
            <row>
              <entry>
                <para> Entire adapter assigned to OS, IOV enabled</para>
              </entry>
              <entry>
                <para>n/a</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>n/a</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Adapter can be shared across multiple OSs, IOV enabled</para>
              </entry>
              <entry>
                <para>n/a</para>
              </entry>
              <entry>
                <para>n/a</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Function DD support</para>
              </entry>
              <entry>
                <para>Plain Function only<?linebreak?>
                (not VF or PF) </para>
              </entry>
              <entry>
                <para>VF only</para>
              </entry>
              <entry>
                <para>VF only</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>PFs managed by platform?</para>
              </entry>
              <entry>
                <para>n/a</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Managed environment support?</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Non-managed environment support?</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>no</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>OS controlled Hot Plug capable?</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>no</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>DLPAR capable?</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>All functions under one PHB in the OF Device Tree for the adapter?</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>no</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>All functions under separate PHBs in the OF Device Tree 
                for the same adapter<footnote xml:id="pgfId-545449"><para>The adapter is 
                physically under one PHB, but the platform creates separate 
                &#x201C;virtual&#x201D; PHBs in the OF Device Tree and virtualizes the PCI 
                Express configuration space for the various functions.</para></footnote>?</para>
              </entry>
              <entry>
                <para>no</para>
              </entry>
              <entry>
                <para>no</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
            </row>
            <row>
              <entry>
                <para><emphasis>config_addr</emphasis> translation 
                (virtualization) by the platform (that is, the bus/device/function of the 
                <emphasis>config_addr</emphasis> does not necessarily correspond to what the 
                device has programmed)</para>
              </entry>
              <entry>
                <para>no</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
            </row>
            <row>
              <entry>
                <para>Shared PE domain (for example, shared EEH domain, shared DMA window)</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>yes</para>
              </entry>
              <entry>
                <para>no</para>
              </entry>
            </row>
          </tbody>
        </tgroup>
      </table>

      <variablelist>
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="sec_pcie_iov" 
          xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
            <listitem>
              <para>PCI Express Single Root IOV (SR-IOV) 
              adapters must comply to the <xref linkend="dbdoclet.50569387_94229"/>.</para>
            </listitem>
       	</varlistentry>
       	
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="sec_pcie_iov" 
          xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
            <listitem>
              <para>PCI Express Multi-Root IOV (MR-IOV) 
              adapters must comply to the <xref linkend="dbdoclet.50569387_42471"/>.</para>
            </listitem>
       	</varlistentry>
       	
       	<varlistentry>
          <term><emphasis role="bold">R1-<xref linkend="sec_pcie_iov" 
          xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
            <listitem>
              <para>The platform must present within the 
              device tree nodes for all PCI Express adapters configured to operate in IOV 
              mode the <emphasis role="bold"><literal>"ibm,is-vf"</literal></emphasis> property as defined in section 
              <xref linkend="LoPAR.RTAS"/>. </para>
            </listitem>
       	</varlistentry>
      </variablelist>
    </section>
  </section>

  <section xml:id="sec_multi_init_scsi">
    <title>Multi-Initiator SCSI Support</title>
    <para>Multi-initiator SCSI support is identified in the OF device tree.</para>

    <variablelist>
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_multi_init_scsi" 
        xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
          <listitem>
            <para><emphasis role="bold">Platform Implementation:</emphasis> 
            Platforms must support the <emphasis role="bold"><literal>&#x201C;scsi-initiator-id&#x201D;</literal></emphasis>
            property as described in <xref linkend="LoPAR.DeviceTree"/> and <xref linkend="dbdoclet.50569387_27008"/>.</para>
          </listitem>
     	</varlistentry>
    </variablelist>
  </section>

  <section xml:id="sec_contig_mem">
    <title>Contiguous Memory </title>
    <para>I/O devices that require contiguous memory pages (either real or via 
    contiguous TCEs) cannot reasonably be accommodated in LoPAR platforms. When 
    TCEs are turned off, that would require that real physical memory addresses be 
    allocated. When TCEs are on, that would require contiguous TCEs be assigned, 
    and although that is the first attempt by the OS&#x2019;s TCE assignment 
    algorithm, the algorithm will assign non-contiguous ones if contiguous ones 
    cannot be assigned. Dynamic Reconfiguration complicates the contiguous problem 
    even further.</para>

    <variablelist>
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_contig_mem" 
        xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
          <listitem>
            <para>I/O devices and/or their device drivers used 
            in LoPAR platforms must implement scatter/gather capability for DMA operations 
            such that they do not require contiguous memory pages to be allocated for 
            proper operation. </para>
          </listitem>
     	</varlistentry>
    </variablelist>
  </section>

  <section xml:id="sec_redirect_serial_ports">
    <title>Re-directed Serial Ports</title>
    <para>The <emphasis role="bold"><literal>&#x201C;ibm,vty-wrap-capable&#x201D;</literal></emphasis> OF 
    device tree property will be present in an OF device tree of a serial port node 
    when the OS data communication with that serial port controller can be 
    redirected, or wrapped, away from the physical serial port connector to an 
    <emphasis>ibm,vty</emphasis> device, which is often a virtual terminal session 
    of the Hardware Management Console (HMC). This property indicates to serial 
    port diagnostic programs that additional end user information should be 
    displayed during the serial port diagnostic test indicating that it is possible 
    that serial port data could be redirected away from the physical serial port 
    preventing the execution of wrap tests with physical wrap plugs. The end user 
    information should describe that initiating a virtual terminal session causes 
    the serial port controller's data to be wrapped away from the physical serial 
    port connection and that terminating a virtual terminal session causes the 
    serial port controller's data to be returned to the physical serial port 
    connection. The <emphasis role="bold"><literal>&#x201C;ibm,vty-wrap-capable&#x201D;</literal></emphasis> 
    property is present with a value of null when this re-direction capability 
    exists and is absent when this capability does not exist. </para>

    <variablelist>
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_redirect_serial_ports" 
        xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
          <listitem>
            <para>The <emphasis role="bold"><literal>&#x201C;ibm,vty-wrap-capable&#x201D;</literal></emphasis> 
            OF device tree property must 
            be present in an OF device tree of a serial port node when the OS data 
            communication with that serial port controller can be redirected, or wrapped, 
            away from the physical serial port connector to an ibm,vty device, and must not 
            be present if this capability does not exist.</para>
          </listitem>
     	</varlistentry>
    </variablelist>
  </section>

  <section xml:id="sec_sys_bus_ioas">
    <title>System Bus IOAs</title>
    <para>This section lists the requirements for the systems to support IOAs 
    connected to the system bus or main I/O expansion bus.</para>

    <variablelist>
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_sys_bus_ioas" 
        xrefstyle="select: labelnumber nopage"/>-1.</emphasis></term>
          <listitem>
            <para>Each system bus IOA must be a bus 
            master.</para>
          </listitem>
     	</varlistentry>
     	
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_sys_bus_ioas" 
        xrefstyle="select: labelnumber nopage"/>-2.</emphasis></term>
          <listitem>
            <para>Firmware must assign unique addresses to all 
            system bus IOA facilities. </para>
          </listitem>
     	</varlistentry>
     	
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_sys_bus_ioas" 
        xrefstyle="select: labelnumber nopage"/>-3.</emphasis></term>
          <listitem>
            <para>Addresses assigned to system bus IOA 
            facilities must not conflict with the addresses mapped by any host bridge on 
            the system bus.</para>
          </listitem>
     	</varlistentry>
     	
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_sys_bus_ioas" 
        xrefstyle="select: labelnumber nopage"/>-4.</emphasis></term>
          <listitem>
            <para>System bus IOAs must be assigned interrupt 
            sources for their interrupt requirements by firmware. </para>
          </listitem>
     	</varlistentry>
     	
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_sys_bus_ioas" 
        xrefstyle="select: labelnumber nopage"/>-5.</emphasis></term>
          <listitem>
            <para>A system bus IOA&#x2019;s OF 
            <emphasis role="bold"><literal>&#x201C;interrupts&#x201D;</literal></emphasis> property must reflect 
            the interrupt source and type allocation for the device.</para>
          </listitem>
     	</varlistentry>
     	
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_sys_bus_ioas" 
        xrefstyle="select: labelnumber nopage"/>-6.</emphasis></term>
          <listitem>
            <para>All system bus IOA interrupts must be low 
            true level sensitive (referred to as level sensitive).</para>
          </listitem>
     	</varlistentry>
     	
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_sys_bus_ioas" 
        xrefstyle="select: labelnumber nopage"/>-7.</emphasis></term>
          <listitem>
            <para>Interrupts assigned to system bus IOAs must 
            not be shared with other IOAs.</para>
          </listitem>
     	</varlistentry>
     	
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_sys_bus_ioas" 
        xrefstyle="select: labelnumber nopage"/>-8.</emphasis></term>
          <listitem>
            <para> The OF unit address (first entry of the 
            <emphasis role="bold"><literal>&#x201C;reg&#x201D;</literal></emphasis> property) of a system 
            bus IOA must stay the same from boot to boot.</para>
          </listitem>
     	</varlistentry>
     	
     	<varlistentry>
        <term><emphasis role="bold">R1-<xref linkend="sec_sys_bus_ioas" 
        xrefstyle="select: labelnumber nopage"/>-9.</emphasis></term>
          <listitem>
            <para>Each system bus IOA must have documentation 
            for programming the IOA and an OF binding which describes at least the 
            <emphasis role="bold"><literal>&#x201C;name&#x201D;</literal></emphasis>, 
            <emphasis role="bold"><literal>&#x201C;reg&#x201D;</literal></emphasis>, 
            <emphasis role="bold"><literal>&#x201C;interrupts&#x201D;</literal></emphasis>, and 
            <emphasis role="bold"><literal>&#x201C;interrupt-parent&#x201D;</literal></emphasis> 
            properties for the device.</para>
          </listitem>
     	</varlistentry>
    </variablelist>

  </section>
</chapter>
