[xen-unstable-smoke test] 165243: regressions - FAIL

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf                   6 xen-build                fail REGR. vs. 165233

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 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                  9c3b9800e2019c93ab22da69e4a0b22d6fb059ec
baseline version:
 xen                  890ceb9453171c85e881103e65dbb5cdcf81659e

Last test of basis   165233  2021-09-28 12:00:26 Z    0 days
Testing same since   165243  2021-09-28 17:00:26 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  fail    
 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


Not pushing.

------------------------------------------------------------
commit 9c3b9800e2019c93ab22da69e4a0b22d6fb059ec
Author: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
Date:   Tue Sep 28 16:04:50 2021 +0200

    pci: fix handling of PCI bridges with subordinate bus number 0xff
    
    Bus number 0xff is valid according to the PCI spec. Using u8 typed sub_bus
    and assigning 0xff to it will result in the following loop getting stuck.
    
        for ( ; sec_bus <= sub_bus; sec_bus++ ) {...}
    
    Just change its type to unsigned int similarly to what is already done in
    dmar_scope_add_buses().
    
    Signed-off-by: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>

commit 1578322ac6bc4d66800a5a3caf6685f556b64054
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Tue Sep 28 16:03:38 2021 +0200

    x86/PVH: actually show Dom0's register state from debug key '0'
    
    vcpu_show_registers() didn't do anything for HVM so far. Note though
    that some extra hackery is needed for VMX - see the code comment.
    
    Note further that the show_guest_stack() invocation is left alone here:
    While strictly speaking guest_kernel_mode() should be predicated by a
    PV / !HVM check, show_guest_stack() itself will bail immediately for
    HVM.
    
    While there and despite not being PVH-specific, take the opportunity and
    filter offline vCPU-s: There's not really any register state associated
    with them, so avoid spamming the log with useless information while
    still leaving an indication of the fact.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
(qemu changes not included)