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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs. 
127212

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 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                  a9a2a761f75126d908612c64fabe6adde2b6d2b9
baseline version:
 xen                  16bbf8e7b39b50457bb2f6547f166bd54d50e4cd

Last test of basis   127212  2018-09-03 13:00:29 Z    0 days
Failing since        127215  2018-09-03 16:00:27 Z    0 days    3 attempts
Testing same since   127219  2018-09-03 19:00:33 Z    0 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  Roger Pau Monné <roger.pau@xxxxxxxxxx>
  Tim Deegan <tim@xxxxxxx>

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                                      pass    
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     fail    
 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 a9a2a761f75126d908612c64fabe6adde2b6d2b9
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Aug 1 13:48:33 2018 +0000

    x86/hvm: Fix mapping corner case during task switching
    
    hvm_map_entry() can fail for a number of reasons, including for a misaligned
    LDT/GDT access which crosses a 4K boundary.  Architecturally speaking, this
    should be fixed, but Long Mode doesn't support task switches, and no 32bit 
OS
    is going to misalign its LDT/GDT base, which is why this task isn't very 
high
    on the TODO list.
    
    However, the hvm_map_fail error label returns failure without raising an
    exception, which interferes with hvm_task_switch()'s exception tracking, and
    can cause it to finish and return to guest context as if the task switch had
    completed successfully.
    
    Resolve this corner case by folding all the failure paths together, which
    causes an hvm_map_entry() failure to result in #TS[SEL].  hvm_unmap_entry()
    copes fine with a NULL pointer so can be called unconditionally.
    
    In practice, this is just a latent corner case as all hvm_map_entry() 
failures
    crash the domain, but it should be fixed nevertheless.
    
    Finally, rename hvm_load_segment_selector() to task_switch_load_seg() to 
avoid
    giving the impression that it is usable for general segment loading.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 1f0598a1beb6bbaa838dec4f321af543d3b96c7a
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Wed Jan 24 16:43:55 2018 +0000

    x86/mm: Drop {HAP,SHADOW}_ERROR() wrappers
    
    Unlike the PRINTK/DEBUG wrappers, these go straight out to the console, 
rather
    than ending up in the debugtrace buffer.
    
    A number of these users are followed by domain_crash(), and future changes
    will want to combine the printk() into the domain_crash() call.  Expand 
these
    wrappers in place, using XENLOG_ERR before a BUG(), and XENLOG_G_ERR before 
a
    domain_crash().
    
    Perfom some %pv/PRI_mfn/etc cleanup while modifying the invocations, and
    explicitly drop some calls which are unnecessary (bad shadow op, and the 
empty
    stubs for incorrect sh_map_and_validate_gl?e() calls).
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by:  Tim Deegan <tim@xxxxxxx>

commit 4f9b0dbb33aca70cdb61c2988866cbedb4181702
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Sep 3 17:45:52 2018 +0100

    xen/x86: Ignore the automatically generated include/asm-x86/asm-macros.h
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>

commit 09b3907f93fe023ebca809c9f706f3d022801dce
Author: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Date:   Mon Sep 3 17:54:12 2018 +0200

    The hvmloader binary generated when using LLVM LD doesn't work
    properly and seems to get stuck while trying to generate and load the
    ACPI tables. This is caused by the layout of the binary when linked
    with LLVM LD.
    
    LLVM LD has a different default linker script that GNU LD, and the
    resulting hvmloader binary is slightly different:
    
    LLVM LD:
    Program Headers:
      Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
      PHDR           0x000034 0x000ff034 0x000ff034 0x00060 0x00060 R   0x4
      LOAD           0x000000 0x000ff000 0x000ff000 0x38000 0x38000 RWE 0x1000
      GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0
    
    GNU LD:
    Program Headers:
      Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
      LOAD           0x000080 0x00100000 0x00100000 0x36308 0x3fd74 RWE 0x10
      GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
    
    Note that in the LLVM LD case (as with GNU LD) the .text section does
    indeed have the address set to 0x100000 as requested on the command
    line:
    
    [ 1] .text             PROGBITS        00100000 001000 00dd10 00  AX  0   0 
16
    
    There's however the PHDR which is not present when using GNU LD.
    
    Fix this by using a very simple linker script that generates the same
    binary regardless of whether LLVM or GNU LD is used. By using a linker
    script the usage of -Ttext can also be avoided by placing the desired
    .text load address directly in the linker script.
    
    Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 936b77255269b3b9b5685d565550e77d5080ac81
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon Sep 3 17:51:40 2018 +0200

    x86/boot: silence MADT table entry logging
    
    Logging disabled LAPIC / x2APIC entries with invalid local APIC IDs
    (ones having "broadcast" meaning when used) isn't very useful, and can
    be quite noisy on larger systems. Suppress their logging unless
    opt_cpu_info is true.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 3f2002614af51dfd507168a1696658bac91155ce
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Mon Sep 3 17:50:10 2018 +0200

    x86: assorted array_index_nospec() insertions
    
    Don't chance having Spectre v1 (including BCBS) gadgets. In some of the
    cases the insertions are more of precautionary nature rather than there
    provably being a gadget, but I think we should err on the safe (secure)
    side here.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
    Acked-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
(qemu changes not included)

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

 


Rackspace

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