[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1)         blocked n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-armhf-armhf-xl           1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
baseline version:
 xen                  94bd9df0f7efad8038d99ec52ba56ecec4191248

Last test of basis   129852  2018-11-12 16:00:37 Z    0 days
Testing same since   129861  2018-11-12 19:00:52 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>

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


------------------------------------------------------------
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 011319e9ce110c70a3d52f2ea05e5eeb538c9e9e
Author: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date:   Fri Nov 2 13:46:11 2018 -0400

    flask/policy: allow dom0 to use PHYSDEVOP_pci_mmcfg_reserved
    
    Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 27bd5ef5c8ac2791ee8bc8033ee8d994ec6a496f
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 18 11:30:27 2018 +0100

    x86/cpuid: Tie SMAP to NX, for the shadow pagetable code
    
    NX support in the host is required for the shadow pagetable code to handle
    SMAP correctly for guests.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit fd35f32b4b8ae89080d247bc901c1b0ad66f37a8
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Jul 19 16:51:57 2018 +0100

    tools/x86emul: Use struct cpuid_policy in the userspace test harnesses
    
    This will shortly be required to pass into the emulator itself.
    
    Simplify the shared cpu_has_* helpers by reading the correct bit out of the
    CPUID policy itself.
    
    No (intended) change in behaviour.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit c66ef0fbe12b3e1e2da849dd85e5b7fe3aa81de5
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Jul 19 16:50:03 2018 +0100

    libx86: Split x86_cpuid_policy_fill_native() out of calculate_raw_policy()
    
    This will shortly be wanted by the userspace emulator harnesses as well.
    
    Consolidate the cpuid{,_count}_leaf() helpers beside the structure 
definition,
    rather than having them scattered throughout Xen.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit c49338ef287c44113476d4c6ccaad7fa2924f8c7
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Mon Nov 12 17:14:57 2018 +0100

    guest/pvh: special case the low 1MB
    
    When running as a PVH guest Xen only special cases the trampoline
    code in the low 1MB, without also reserving the space used by the
    relocated metadata or the trampoline stack.
    
    Fix this by always reserving the low 1MB regardless of whether Xen is
    running as a guest or natively.
    
    Reported-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit c6aae55786e138951daf25e14709895d8c166948
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Mon Nov 12 17:13:57 2018 +0100

    guest/pvh: fix handling of multiboot module list
    
    When booting Xen as a PVH guest the data in the PVH start info
    structure is copied over to a multiboot structure and a module list
    array that resides in the .init section of the Xen image. The
    resulting multiboot module list is then handed to the generic boot
    process using the physical address in mbi->mods_addr.
    
    This works fine as long as the Xen image doesn't relocate itself, if
    there's such a relocation the physical addresses of multiboot module
    list is no longer valid.
    
    Fix this by handing the virtual address of the module list to the
    generic boot process instead of it's physical address.
    
    Reported-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
(qemu changes not included)

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/osstest-output

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.