[Xen-devel] [ovmf baseline-only test] 72194: all pass

[Platform Team regression test user <citrix-osstest@xxxxxxxxxxxxxx>]

This run is configured for baseline tests only.

flight 72194 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72194/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 fe4049471bdf066c3c07dfa76752149743afa16f
baseline version:
 ovmf                 9425b34925d0cf1b96aaf2c316d3299df9780252

Last test of basis    72184  2017-10-03 02:47:49 Z    1 days
Testing same since    72194  2017-10-03 19:22:52 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laszlo Ersek <lersek@xxxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
    http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.

------------------------------------------------------------
commit fe4049471bdf066c3c07dfa76752149743afa16f
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Fri Sep 22 11:23:43 2017 +0200

    OvmfPkg/PciHotPlugInitDxe: translate QEMU's resource reservation hints
    
    Parse QEMU_PCI_BRIDGE_CAPABILITY_RESOURCE_RESERVATION from the bridges'
    conventional config spaces. Translate the fields as follows:
    
    * BusNumbers:
      * 0 -- no reservation;
      * (-1) -- firmware default, i.e. no reservation;
      * otherwise -- reserve the requested value. (NB, bus number reservation
        is not supposed to work before
        <https://bugzilla.tianocore.org/show_bug.cgi?id=656> is fixed.)
    
    * Io:
      * 0 -- no reservation;
      * (-1) -- keep our current default (512B);
      * otherwise -- round up the requested value and reserve that.
    
    * NonPrefetchable32BitMmio:
      * 0 -- no reservation;
      * (-1) -- keep our current default (2MB);
      * otherwise -- round up the requested value and reserve that.
    
    * Prefetchable32BitMmio:
      * 0 -- no reservation, proceed to Prefetchable64BitMmio;
      * (-1) -- firmware default, i.e. no reservation, proceed to
        Prefetchable64BitMmio;
      * otherwise -- round up the requested value and reserve that. (NB, if
        Prefetchable32BitMmio is reserved in addition to
        NonPrefetchable32BitMmio, then PciBusDxe currently runs into an
        assertion failure. Refer to
        <https://bugzilla.tianocore.org/show_bug.cgi?id=720>.)
    
    * Prefetchable64BitMmio:
      * only reached if Prefetchable32BitMmio was not reserved;
      * 0 -- no reservation;
      * (-1) -- firmware default, i.e. no reservation;
      * otherwise -- round up the requested value and reserve that.
    
    If QEMU_PCI_BRIDGE_CAPABILITY_RESOURCE_RESERVATION is missing, plus any
    time the rounding fails, fall back to the current defaults.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Marcel Apfelbaum <marcel@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 4776d5cb3abfa2e35fee03c3a3e219648fee3761
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Fri Sep 22 00:31:12 2017 +0200

    OvmfPkg/PciHotPlugInitDxe: add helper functions for setting up paddings
    
    Extract the SetIoPadding() and SetMmioPadding() functions, so that we can
    set EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR fields using parameter names and
    values that are more friendly than the original field names and their
    expected values.
    
    Introduce the HighBitSetRoundUp32() and HighBitSetRoundUp64() functions
    for calculating the last parameter ("SizeExponent") of SetIoPadding() and
    SetMmioPadding().
    
    Put the new functions to use when requesting the default reservations. (In
    order to be consistent with a later patch, "SizeExponent" is calculated
    for SetIoPadding() with HighBitSetRoundUp64().)
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Marcel Apfelbaum <marcel@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit a980324709b195dfe3f83741a7319cc9dc7a2efd
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Sep 21 14:33:56 2017 +0200

    OvmfPkg/PciHotPlugInitDxe: generalize RESOURCE_PADDING composition
    
    PciHotPlugInitDxe has a static variable called "mPadding" (of type
    RESOURCE_PADDING), which describes two constant resource reservations:
    
    - MmioPadding: 2MB of non-prefetchable (hence 32-bit) MMIO space,
    
    - IoPadding: 512B of IO space.
    
    In the GetResourcePadding() member function of
    EFI_PCI_HOT_PLUG_INIT_PROTOCOL, the driver outputs a dynamically allocated
    verbatim copy of "mPadding", for PciBusDxe to consume in its
    ApplyResourcePadding() function.
    
    In a later patch, we're going to compose the set of resource reservations
    dynamically, based on QEMU hints. Generalize the RESOURCE_PADDING
    structure so that we may generate (or not generate) each resource type
    individually:
    
    - Replace the named "MmioPadding" and "IoPadding" fields in
      RESOURCE_PADDING with an array of descriptors,
    
    - remove "mPadding",
    
    - in GetResourcePadding(), request the same (default) reservations as
      before, as if we attempted and failed to fetch the QEMU hints.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Marcel Apfelbaum <marcel@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit c18ac9fbcc71dd75f1f8cb84b6c929536c1ef580
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Sep 21 13:18:11 2017 +0200

    OvmfPkg/PciHotPlugInitDxe: clean up addr. range for non-prefetchable MMIO
    
    The non-prefetchable MMIO aperture of a bridge can never fall outside of
    the 32-bit address space. Namely, the MemoryBase and MemoryLimit fields in
    PCI_BRIDGE_CONTROL_REGISTER have type UINT16, and based on the PCI-to-PCI
    Bridge Architecture Spec, Chapter 3.2, the actual MMIO aperture is
    determined as in:
    
    NonPrefetchMemoryBase  = (((MemoryBase  & 0xFFF0u) >> 4) << 20) | 0x00000
    NonPrefetchMemoryLimit = (((MemoryLimit & 0xFFF0u) >> 4) << 20) | 0xFFFFF
    
    In "OvmfPkg/PciHotPlugInitDxe", the
    "mPadding.MmioPadding.AddrSpaceGranularity" field is currently initialized
    to 64. According to the above, this is useless generality: a
    non-prefetchable MMIO reservation may only be satisfied from 32-bit
    address space. Update the field to 32.
    
    In practice this change makes no difference, because PciBusDxe already
    enforces the 32-bit limitation when it sees "non-prefetchable" from
    (SpecificFlag==0). Quoting commit 8aba40b79267 ("OvmfPkg: add
    PciHotPlugInitDxe", 2016-06-30): "regardless of our request for 64-bit
    MMIO reservation, it is downgraded to 32-bit".
    
    (See the Platform Init Spec 1.6, Volume 5,
    - Table 8. "ACPI 2.0 & 3.0 QWORD Address Space Descriptor Usage", and
    - Table 11. "Memory Resource Flag (Resource Type = 0) Usage",
    for an explanation of the "mPadding.MmioPadding" fields.)
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Marcel Apfelbaum <marcel@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Fixes: 8aba40b79267df761bd24d6874ae87f47a7bd3de
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 91231fc2ff2b5d113cccdb560515a7f591f7502d
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Sep 21 12:08:31 2017 +0200

    OvmfPkg/PciHotPlugInitDxe: clean up protocol usage comment
    
    The driver always produces an instance of the
    EFI_PCI_HOT_PLUG_INIT_PROTOCOL. The "SOMETIMES_PRODUCES" remark is an
    oversight from the original v1->v2 patch update; v2 should have stated
    "ALWAYS_PRODUCES":
    
    
http://mid.mail-archive.com/1468242274-12686-5-git-send-email-lersek@xxxxxxxxxx
    
    > Notes:
    >     v2:
    >     - drop the PcdPciBusHotplugDeviceSupport check, and the PcdLib
    >       dependency with it [Jordan]
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Marcel Apfelbaum <marcel@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Fixes: 8aba40b79267df761bd24d6874ae87f47a7bd3de
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit bdf73b57f2834f6891a1d0707c0baaaa37169f7b
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Sep 21 11:38:47 2017 +0200

    OvmfPkg/IndustryStandard: define PCI Capabilities for QEMU's PCI Bridges
    
    QEMU has recently gained the ability to provide various hints about its
    PCI bridges. The hints take the form of vendor-specific PCI capabilities.
    Define macros and types under "OvmfPkg/Include/IndustryStandard" to
    describe these capabilities.
    
    The definitions correspond to "docs/pcie_pci_bridge.txt" in the QEMU tree.
    Said documentation was added in the last commit of the following series:
    
      a35fe226558a hw/pci: introduce pcie-pci-bridge device
      70e1ee59bb94 hw/pci: introduce bridge-only vendor-specific capability to
                   provide some hints to firmware
      226263fb5cda hw/pci: add QEMU-specific PCI capability to the Generic PCI
                   Express Root Port
      c1800a162765 docs: update documentation considering PCIE-PCI bridge
    
    We are going to parse the Resource Reservation Capability in
    OvmfPkg/PciHotPlugInitDxe, and return the reservation requests to
    PciBusDxe.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Marcel Apfelbaum <marcel@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 8844f15d33c720323227ce61b518aed4549f19d0
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu Sep 21 10:48:53 2017 +0200

    MdePkg/IndustryStandard/Pci23: add vendor-specific capability header
    
    Revision 2.2 of the PCI Spec defines Capability IDs 0 through 6,
    inclusive, in Appendix H. It reserves IDs 7 through 255.
    
    Revision 2.3 of the PCI Spec adds Capability IDs 7 through 0xC, inclusive,
    in Appendix H. Capability ID 9 stands for "Vendor Specific".
    
    Add the EFI_PCI_CAPABILITY_ID_VENDOR macro and the
    EFI_PCI_CAPABILITY_VENDOR_HDR structure type to MdePkg/IndustryStandard,
    in order to describe this capability header.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Cc: Marcel Apfelbaum <marcel@xxxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel