[Xen-devel] [xen-unstable-smoke test] 128019: regressions - FAIL

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm       7 xen-boot                 fail REGR. vs. 127928

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  1bd9cc34e152addeacbbf44898125c7be00e7677
baseline version:
 xen                  940185b2f6f343251c2b83bd96e599398cea51ec

Last test of basis   127928  2018-09-22 10:00:53 Z    2 days
Failing since        128013  2018-09-24 14:00:44 Z    0 days    2 attempts
Testing same since   128019  2018-09-24 18:00:28 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Amit Singh Tomar <amittomer25@xxxxxxxxx>
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      fail    
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     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 1bd9cc34e152addeacbbf44898125c7be00e7677
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Fri Sep 21 16:54:52 2018 +0100

    x86: expose CONFIG_HVM
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 026eac063bf756e9f5aa9afa1e4cb6b50dcf2a5b
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Fri Sep 21 16:54:51 2018 +0100

    x86/mm: put HVM only code under CONFIG_HVM
    
    Going through the code, HAP, EPT, PoD and ALTP2M depend on HVM code.
    Put these components under CONFIG_HVM. This further requires putting
    one of the vm event under CONFIG_HVM.
    
    Altp2m requires a bit more attention because its code is embedded in
    generic x86 p2m code.
    
    Also make hap_enabled evaluate to false when !CONFIG_HVM. Make sure it
    evaluate its parameter to avoid unused variable warnings in its users.
    
    Also sort items in Makefile while at it.
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit 9629b62005fa88424a4f48102848c4524d0341e3
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Fri Sep 21 16:54:50 2018 +0100

    x86/mm: put nested p2m code under CONFIG_HVM
    
    These functions are only useful for nested hvm, which isn't enabled
    when CONFIG_HVM is false.
    
    Enclose relevant code and fields in CONFIG_HVM.
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit 72a901d7a04305f24f7b1e723e6cf18c744cff95
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Fri Sep 21 16:54:49 2018 +0100

    x86/p2m/pod: make it build with !CONFIG_HVM
    
    Populate-on-demand is HVM only.
    
    Provide a bunch of stubs for common p2m code and guard one invocation
    of guest_physmap_mark_populate_on_demand with is_hvm_domain.
    
    Put relevant fields in p2m_domain and code which touches those fields
    under CONFIG_HVM.
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
    Reviewed-by: George Dunlap <george.dunlap@xxxxxxxxxx>

commit 39d42a2daee3d0b4c12ce7391faf4763eff09e6b
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Feb 21 17:54:13 2018 +0000

    x86: Clean up the Xen MSR infrastructure
    
    Rename them to guest_{rd,wr}msr_xen() for consistency, and because the _regs
    suffix isn't very appropriate.
    
    Update them to take a vcpu pointer rather than presuming that they act on
    current, and switch to using X86EMUL_* return values.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 229b94878717e22c0f228625bbcddd53f7d8654d
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Sep 20 17:33:59 2017 +0000

    x86/viridan: Clean up Viridian MSR infrastructure
    
    Rename the functions to guest_{rd,wr}msr_viridian() for consistency, and
    because the _regs() suffix isn't very appropriate.
    
    Update them to take a vcpu pointer rather than presuming that they act on
    current, which is safe for all implemented operations, and switch their 
return
    ABI to use X86EMUL_*.
    
    The default cases no longer need to deal with MSRs out of the Viridian 
range,
    but drop the printks to debug builds only and identify the value attempting 
to
    be written.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit bd7099a674819c0709bd058793adea2e76b42a6b
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Sep 20 18:33:59 2017 +0100

    x86/msr: Dispatch Xen and Viridian MSRs from guest_{wr,rd}msr()
    
    Despite the complicated diff in {svm,vmx}_msr_write_intercept(), it is just
    the 0 case losing one level of indentation, as part of removing the call to
    wrmsr_hypervisor_regs().
    
    The case blocks in guest_{wr,rd}msr() use raw numbers, partly for 
consistency
    with the CPUID side of things, but mainly because this is clearer code to
    follow.  In particular, the Xen block may overlap with the Viridian block if
    Viridian is not enabled for the domain, and trying to express this with 
named
    literals caused more confusion that it solved.
    
    Future changes with clean up the individual APIs, including allowing these
    MSRs to be usable for vcpus other than current (no callers exist with v !=
    current).
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit cd8015b634b005a3911bd6025351cd854d63a82a
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Sep 24 14:00:02 2018 +0100

    ARM/dom0: Avoid using a variable length array in make_memory_node()
    
    The reg[] array can have a maximum size of 8 in practice, so use the worst
    case calculation rather than making it variable length.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Julien Grall <julien.grall@xxxxxxx>

commit 17bd254a508f4174fe0d56a9f1b9892b7649b4b9
Author: Amit Singh Tomar <amittomer25@xxxxxxxxx>
Date:   Tue Sep 11 22:18:06 2018 +0530

    xen:arm: Populate arm64 image header
    
    This patch adds image size and flags to XEN image header. It uses
    those fields according to the updated Linux kernel image definition.
    
    With this patch bootloader can now place XEN image anywhere in system
    RAM at 2MB aligned address without to worry about relocation.
    For instance, it fixes the XEN boot on Amlogic SoC where bootloader(U-BOOT)
    always relocates the XEN image to an address range reserved for firmware 
data.
    
    Signed-off-by: Amit Singh Tomar <amittomer25@xxxxxxxxx>
    Reviewed-by: Andre Pryzwara <andre.przywara@xxxxxxx>
    Acked-by: Julien Grall <julien.grall@xxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel