[Xen-devel] [ovmf bisection] complete build-amd64

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build

Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  4275f38507a4a44260555495dfb6da1d8a307307
  Bug not present: b941c34ef859971e29683ffb57c309e24e6a96be
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/110214/


  commit 4275f38507a4a44260555495dfb6da1d8a307307
  Author: Laszlo Ersek <lersek@xxxxxxxxxx>
  Date:   Sat Jun 3 16:11:08 2017 +0200
  
      OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted
      
      ... by narrower than 8-byte ADD_POINTER references.
      
      Introduce the CollectAllocationsRestrictedTo32Bit() function, which
      iterates over the linker/loader script, and collects the names of the
      fw_cfg blobs that are referenced by QEMU_LOADER_ADD_POINTER.PointeeFile
      fields, such that QEMU_LOADER_ADD_POINTER.PointerSize is less than 8. This
      means that the pointee blob's address will have to be patched into a
      narrower-than-8 byte pointer field, hence the pointee blob must not be
      allocated from 64-bit address space.
      
      In ProcessCmdAllocate(), consult these restrictions when setting the
      maximum address for gBS->AllocatePages(). The default is now MAX_UINT64,
      unless restricted like described above to the pre-patch MAX_UINT32 limit.
      
      In combination with Ard's QEMU commit cb51ac2ffe36 ("hw/arm/virt: generate
      64-bit addressable ACPI objects", 2017-04-10), this patch enables
      OvmfPkg/AcpiPlatformDxe to work entirely above the 4GB mark.
      
      (An upcoming / planned aarch64 QEMU machine type will have no RAM under
      4GB at all. Plus, moving the allocations higher is beneficial to the
      current "virt" machine type as well; in Ard's words: "having all firmware
      allocations inside the same 1 GB (or 512 MB for 64k pages) frame reduces
      the TLB footprint".)
      
      Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
      Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx>
      Cc: Igor Mammedov <imammedo@xxxxxxxxxx>
      Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
      Suggested-by: Igor Mammedov <imammedo@xxxxxxxxxx>
      Suggested-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
      Tested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
      Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.

----------------------------------------
Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/ovmf/build-amd64.xen-build 
--summary-out=tmp/110214.bisection-summary --basis-template=110078 
--blessings=real,real-bisect ovmf build-amd64 xen-build
Searching for failure / basis pass:
 110166 fail [host=huxelrebe0] / 110078 ok.
Failure / basis pass flights: 110166 / 110078
(tree with no url: minios)
(tree with no url: seabios)
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
Basis pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
d8eed4021d50eb48ca75c8559aed95a2ad74afaa
Generating revisions with ./adhoc-revtuple-generator  
https://github.com/tianocore/edk2.git#b941c34ef859971e29683ffb57c309e24e6a96be-c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7-e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7
 
git://xenbits.xen.org/xen.git#d8eed4021d50eb48ca75c8559aed95a2ad74afaa-3d2010f9ffeacc8836811420460e15f2c1233695
Loaded 2001 nodes in revision graph
Searching for test results:
 110078 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
d8eed4021d50eb48ca75c8559aed95a2ad74afaa
 110104 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110117 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110139 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110199 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110173 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
d8eed4021d50eb48ca75c8559aed95a2ad74afaa
 110214 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110206 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110192 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110193 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
8fd8951eabc6648fc302585187d02d49157ff907
 110207 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110166 fail c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110194 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
9c4f1b72571b215e80abf0490073438831dc785b
 110196 fail c1f4b86ba786cc9cbe5c88a05abc9bf0554b1cc8 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110197 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3127e85ba934a2be8c16b3277af88ccce948946a
 110208 fail 4275f38507a4a44260555495dfb6da1d8a307307 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
 110213 pass b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
Searching for interesting versions
 Result found: flight 110078 (pass), for basis pass
 Result found: flight 110166 (fail), for basis failure
 Repro found: flight 110173 (pass), for basis pass
 Repro found: flight 110196 (fail), for basis failure
 0 revisions at b941c34ef859971e29683ffb57c309e24e6a96be 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
3d2010f9ffeacc8836811420460e15f2c1233695
No revisions left to test, checking graph state.
 Result found: flight 110199 (pass), for last pass
 Result found: flight 110206 (fail), for first failure
 Repro found: flight 110207 (pass), for last pass
 Repro found: flight 110208 (fail), for first failure
 Repro found: flight 110213 (pass), for last pass
 Repro found: flight 110214 (fail), for first failure

*** Found and reproduced problem changeset ***

  Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  4275f38507a4a44260555495dfb6da1d8a307307
  Bug not present: b941c34ef859971e29683ffb57c309e24e6a96be
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/110214/


  commit 4275f38507a4a44260555495dfb6da1d8a307307
  Author: Laszlo Ersek <lersek@xxxxxxxxxx>
  Date:   Sat Jun 3 16:11:08 2017 +0200
  
      OvmfPkg/AcpiPlatformDxe: alloc blobs from 64-bit space unless restricted
      
      ... by narrower than 8-byte ADD_POINTER references.
      
      Introduce the CollectAllocationsRestrictedTo32Bit() function, which
      iterates over the linker/loader script, and collects the names of the
      fw_cfg blobs that are referenced by QEMU_LOADER_ADD_POINTER.PointeeFile
      fields, such that QEMU_LOADER_ADD_POINTER.PointerSize is less than 8. This
      means that the pointee blob's address will have to be patched into a
      narrower-than-8 byte pointer field, hence the pointee blob must not be
      allocated from 64-bit address space.
      
      In ProcessCmdAllocate(), consult these restrictions when setting the
      maximum address for gBS->AllocatePages(). The default is now MAX_UINT64,
      unless restricted like described above to the pre-patch MAX_UINT32 limit.
      
      In combination with Ard's QEMU commit cb51ac2ffe36 ("hw/arm/virt: generate
      64-bit addressable ACPI objects", 2017-04-10), this patch enables
      OvmfPkg/AcpiPlatformDxe to work entirely above the 4GB mark.
      
      (An upcoming / planned aarch64 QEMU machine type will have no RAM under
      4GB at all. Plus, moving the allocations higher is beneficial to the
      current "virt" machine type as well; in Ard's words: "having all firmware
      allocations inside the same 1 GB (or 512 MB for 64k pages) frame reduces
      the TLB footprint".)
      
      Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
      Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx>
      Cc: Igor Mammedov <imammedo@xxxxxxxxxx>
      Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
      Suggested-by: Igor Mammedov <imammedo@xxxxxxxxxx>
      Suggested-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
      Contributed-under: TianoCore Contribution Agreement 1.0
      Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
      Tested-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
      Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

Revision graph left in 
/home/logs/results/bisect/ovmf/build-amd64.xen-build.{dot,ps,png,html,svg}.
----------------------------------------
110214: tolerable ALL FAIL

flight 110214 ovmf real-bisect [real]
http://logs.test-lab.xenproject.org/osstest/logs/110214/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 build-amd64                   5 xen-build               fail baseline untested


jobs:
 build-amd64                                                  fail    


------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
    http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
    http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


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