[xen-unstable-smoke test] 176301: trouble: blocked/broken/pass

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

flight 176301 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/176301/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                     <job status>                 broken
 build-armhf                   4 host-install(4)        broken REGR. vs. 176151
 build-armhf                   3 syslog-server                running

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 build-armhf                   5 capture-logs          broken blocked in 176151
 test-amd64-amd64-libvirt     15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      15 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      16 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  78e93e6e57c218eead498a664785f414bcb12460
baseline version:
 xen                  10b80ee5588e8928b266dea02a5e99d098bd227a

Last test of basis   176151  2023-01-26 14:00:29 Z    5 days
Testing same since   176283  2023-01-30 21:02:20 Z    0 days   10 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
  Stefano Stabellini <stefano.stabellini@xxxxxxx>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  broken  
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          blocked 
 test-arm64-arm64-xl-xsm                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-amd64                    pass    
 test-amd64-amd64-libvirt                                     pass    


------------------------------------------------------------
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

broken-job build-armhf broken
broken-step build-armhf host-install(4)
broken-step build-armhf capture-logs

Not pushing.

------------------------------------------------------------
commit 78e93e6e57c218eead498a664785f414bcb12460
Author: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
Date:   Wed Jan 25 11:21:31 2023 +0000

    xen/arm: Probe the load/entry point address of an uImage correctly
    
    Currently, kernel_uimage_probe() does not read the load/entry point address
    set in the uImge header. Thus, info->zimage.start is 0 (default value). This
    causes, kernel_zimage_place() to treat the binary (contained within uImage)
    as position independent executable. Thus, it loads it at an incorrect
    address.
    
    The correct approach would be to read "uimage.load" and set
    info->zimage.start. This will ensure that the binary is loaded at the
    correct address. Also, read "uimage.ep" and set info->entry (ie kernel entry
    address).
    
    If user provides load address (ie "uimage.load") as 0x0, then the image is
    treated as position independent executable. Xen can load such an image at
    any address it considers appropriate. A position independent executable
    cannot have a fixed entry point address.
    
    This behavior is applicable for both arm32 and arm64 platforms.
    
    Earlier for arm32 and arm64 platforms, Xen was ignoring the load and entry
    point address set in the uImage header. With this commit, Xen will use them.
    This makes the behavior of Xen consistent with uboot for uimage headers.
    
    Users who want to use Xen with statically partitioned domains, can provide
    non zero load address and entry address for the dom0/domU kernel. It is
    required that the load and entry address provided must be within the memory
    region allocated by Xen.
    
    A deviation from uboot behaviour is that we consider load address == 0x0,
    to denote that the image supports position independent execution. This
    is to make the behavior consistent across uImage and zImage.
    
    Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@xxxxxxx>
    [stefano: minor doc improvement]
    Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
(qemu changes not included)