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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           5 host-ping-check-native   fail REGR. vs. 129151

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 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                  f993c3e90728705dacd834b49a6e5608c1360409
baseline version:
 xen                  ce75973a273f6cacce2b2b8ace1d3ab4b304c361

Last test of basis   129151  2018-10-29 22:00:24 Z    0 days
Testing same since   129189  2018-10-30 14:00:42 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Kevin Tian <kevin.tian@xxxxxxxxx>

jobs:
 build-arm64-xsm                                              pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          fail    
 test-arm64-arm64-xl-xsm                                      pass    
 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 f993c3e90728705dacd834b49a6e5608c1360409
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Oct 30 11:17:00 2018 +0000

    x86/pv: Fix crash when using `xl set-parameter pcid=...`
    
    "pcid=" is registered as a runtime parameter, which means that parse_pcid()
    must not reside in .init, or the following happens when parse_params() tries
    to call an unmapped function pointer.
    
      (XEN) ----[ Xen-4.12-unstable  x86_64  debug=y   Not tainted ]----
      (XEN) CPU:    0
      (XEN) RIP:    e008:[<ffff82d080407fb3>] ffff82d080407fb3
      (XEN) RFLAGS: 0000000000010292   CONTEXT: hypervisor (d0v1)
      (XEN) rax: ffff82d080407fb3   rbx: ffff82d0803cf270   rcx: 
0000000000000000
      (XEN) rdx: ffff8300abe67fff   rsi: 000000000000000a   rdi: 
ffff8300abe67bfd
      (XEN) rbp: ffff8300abe67ca8   rsp: ffff8300abe67ba0   r8:  
ffff83084d980000
      (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 
0000000000000000
      (XEN) r12: ffff8300abe67bfd   r13: ffff82d0803cb628   r14: 
0000000000000000
      (XEN) r15: ffff8300abe67bf8   cr0: 0000000080050033   cr4: 
0000000000172660
      (XEN) cr3: 0000000828efd000   cr2: ffff82d080407fb3
      (XEN) fsb: 00007fb810d4b780   gsb: ffff88007ce20000   gss: 
0000000000000000
      (XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e010   cs: e008
      (XEN) Xen code around <ffff82d080407fb3> (ffff82d080407fb3) [fault on 
access]:
      (XEN)  -- -- -- -- -- -- -- -- <--> -- -- -- -- -- -- -- -- -- -- -- -- 
-- -- --
      (XEN) Xen stack trace from rsp=ffff8300abe67ba0:
      (XEN)    ffff82d080217f61 ffff830826db0f09 ffff8300abe67bf8 
ffff82d0803cf1e0
      (XEN)    00007cff54198409 ffff8300abe67bf0 010001d000000000 
0000000000000000
      (XEN)    ffff82d0803cf288 ffff8300abe67c88 ffff82d0805a09c0 
616c620064696370
      (XEN)    00000000aaaa0068 0000000000000296 ffff82d08023d60e 
aaaaaaaaaaaaaaaa
      (XEN)    ffff83084d9b4000 ffff8300abe67c68 ffff82d08024940e 
ffff83083736e000
      (XEN)    0000000000000080 000000000000007a 000000000000000a 
ffff82d08045e61c
      (XEN)    ffff82d080573d80 ffff8300abe67cb8 ffff82d080249805 
80000007fce54067
      (XEN)    fffffffffffffff2 ffff830826db0f00 ffff8300abfa7000 
ffff82d08045e61c
      (XEN)    ffff82d080573d80 ffff8300abe67cb8 ffff82d08021801e 
ffff8300abe67e48
      (XEN)    ffff82d08023f60a ffff83083736e000 0000000000000000 
ffff8300abe67d58
      (XEN)    ffff82d080293d90 0000000000000092 ffff82d08023d60e 
ffff820040006ae0
      (XEN)    0000000000000000 0000000000000000 00007fb810d5c010 
ffff83083736e248
      (XEN)    0000000000000286 ffff8300abe67d58 0000000000000000 
ffff82e010521b00
      (XEN)    0000000000000206 0000000000000000 0000000000000000 
ffff8300abe67e48
      (XEN)    ffff82d080295270 00000000ffffffff ffff83083736e000 
ffff8300abe67e48
      (XEN)    ffff820040006ae0 ffff8300abe67d98 000000120000001c 
00007fb810d5d010
      (XEN)    0000000000000009 0000000000000002 0000000000000001 
00007fb810b53260
      (XEN)    0000000000000001 0000000000000000 0000000000638bc0 
00007fb81066a748
      (XEN)    00007ffe11087881 0000000000000002 0000000000000001 
00007fb810b53260
      (XEN)    0000000000638b60 0000000000000000 00007fb8100322a0 
ffff82d08035d444
      (XEN) Xen call trace:
      (XEN)    [<ffff82d080217f61>] kernel.c#parse_params+0x34a/0x3eb
      (XEN)    [<ffff82d08021801e>] runtime_parse+0x1c/0x1e
      (XEN)    [<ffff82d08023f60a>] do_sysctl+0x108d/0x1241
      (XEN)    [<ffff82d0803535cb>] pv_hypercall+0x1ac/0x4c5
      (XEN)    [<ffff82d08035d4a2>] lstar_enter+0x112/0x120
      (XEN)
      (XEN) Pagetable walk from ffff82d080407fb3:
      (XEN)  L4[0x105] = 00000000abe5c063 ffffffffffffffff
      (XEN)  L3[0x142] = 00000000abe59063 ffffffffffffffff
      (XEN)  L2[0x002] = 000000084d9bf063 ffffffffffffffff
      (XEN)  L1[0x007] = 0000000000000000 ffffffffffffffff
      (XEN)
      (XEN) ****************************************
      (XEN) Panic on CPU 0:
      (XEN) FATAL PAGE FAULT
      (XEN) [error_code=0010]
      (XEN) Faulting linear address: ffff82d080407fb3
      (XEN) ****************************************
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit c238ea3f4caccf36ab1a559f958cbe5192327f6a
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 25 14:11:58 2018 +0100

    x86/vvmx: Don't handle unknown nested vmexit reasons at L0
    
    This is very dangerous from a security point of view, because a missing 
entry
    will cause L2's action to be interpreted as L1's action.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>

commit 307ee30a1429e2f45d505c1299b58090edd81eb0
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 25 15:17:50 2018 +0100

    x86/vvmx: Drop the now-obsolete vmx_inst_check_privilege()
    
    Now that nvmx_handle_vmx_insn() performs all VT-x instruction checks, there 
is
    no need for redundant checking in vmx_inst_check_privilege().  Remove it, 
and
    take out the vmxon_check boolean which was plumbed through 
decode_vmx_inst().
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>

commit 18cef4df8f8bd04a59a218e5f67e7896e43fd07d
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 25 14:40:11 2018 +0100

    x86/vvmx: Unconditionally initialise vmxon_region_pa during vcpu 
construction
    
    This is a stopgap solution until the toolstack side of initialisation can be
    sorted out, but it does result in the nvmx_vcpu_in_vmx() predicate working
    correctly even when nested virt hasn't been enabled for the domain.
    
    Update nvmx_handle_vmx_insn() to include the in-vmx mode check (for all
    instructions other than VMXON) to complete the set of #UD checks.
    
    In addition, sanity check that the nested vmexit handler has worked 
correctly,
    and that we are only providing emulation of the VT-x instructions to L1
    guests.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>

commit 6faff8f9005d685185cd3f4ed116bf45d7d1553f
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Oct 25 14:08:33 2018 +0100

    x86/vvmx: Let L1 handle all the unconditional vmexit instructions
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>

commit 30f43f4aa81e2dea6f754dddaf794518587022c2
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon May 28 15:22:49 2018 +0100

    x86: Reorganise and rename debug register fields in struct vcpu
    
    Reusing debugreg[5] for the PV emulated IO breakpoint information is 
confusing
    to read.  Instead, introduce a dr7_emul field in pv_vcpu for the purpose.
    
    With the PV emulation out of the way, debugreg[4,5] are entirely unused and
    don't need to be stored.
    
    Rename debugreg[0..3] to dr[0..3] to reduce code volume, but keep them as an
    array because their behaviour is identical and this helps simplfy some of 
the
    PV handling.  Introduce dr6 and dr7 fields to replace debugreg[6,7] which
    removes the storage for debugreg[4,5].
    
    In arch_get_info_guest(), handle the merging of emulated dr7 state alongside
    all other dr handling, rather than much later.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

commit 2b3218eb6bf27d3b66885dde8ae05e4e7864370d
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon May 28 15:16:37 2018 +0000

    x86/emul: Unfold %cr4.de handling in x86emul_read_dr()
    
    No functional change (as curr->arch.debugreg[5] is zero when DE is clear), 
but
    this change simplifies the following patch.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

commit 0a1fa635029d100d4b6b7eddb31d49603217cab7
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Oct 29 11:29:54 2018 +0000

    x86/domain: Fix build with GCC 4.3.x
    
    GCC 4.3.x can't initialise the user_regs structure like this.
    
    Reported-by: Jan Beulich <JBeulich@xxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-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®.