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

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

flight 133469 xen-unstable-smoke real [real]

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  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
 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                  1c8ca185e3c6e003398471edd9dbac0cd118137c
baseline version:
 xen                  346e7d0f4b2179b9e0b09f4ebc98cbb3aae39a2c

Last test of basis   133457  2019-02-27 14:00:42 Z    1 days
Testing same since   133469  2019-02-28 12:00:29 Z    0 days    1 attempts

People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  Christian Lindig <christian.lindig@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Kevin Tian <kevin.tian@xxxxxxxxx>
  Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

 build-arm64-xsm                                              pass    
 build-amd64                                                  fail    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          blocked 
 test-armhf-armhf-xl                                          pass    
 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

Explanation of these reports, and of osstest in general, is at

Test harness code can be found at

Not pushing.

commit 1c8ca185e3c6e003398471edd9dbac0cd118137c
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Feb 28 10:48:16 2019 +0000

    x86/hvm: Increase the triple fault log message level to XENLOG_ERR
    At INFO level, it doesn't get printed out by default in release builds,
    leading to unqualified logging such as this:
      (XEN) [   66.995993] Freed 524kB init memory
      (XEN) [ 1993.144997] *** Dumping Dom9 vcpu#2 state: ***
      (XEN) [ 1993.145008] ----[ Xen-4.11.1  x86_64  debug=n   Not tainted ]----
      (XEN) [ 1993.145011] CPU:    21
      (XEN) [ 1993.145015] RIP:    0010:[<ffffe0002ba950ef>]
      (XEN) [ 1993.145018] RFLAGS: 0000000000010246   CONTEXT: hvm guest (d9v2)
      (XEN) [ 1993.145026] rax: 00000000ffffe000   rbx: ffffe0002d8e1440   rcx: 
      (XEN) [ 1993.145031] rdx: 0000000000000000   rsi: ffffe0002ba93575   rdi: 
      (XEN) [ 1993.145035] rbp: ffffd001cd791200   rsp: ffffd001cd791140   r8:  
      (XEN) [ 1993.145039] r9:  0000000080000000   r10: 0000000000000000   r11: 
      (XEN) [ 1993.145043] r12: ffffe0002ba9306d   r13: 0000000000000000   r14: 
      (XEN) [ 1993.145047] r15: fffff803dfb9f200   cr0: 0000000080050031   cr4: 
      (XEN) [ 1993.145051] cr3: 00000000001aa002   cr2: 0000020488403f70
      (XEN) [ 1993.145056] fsb: 0000000060f71000   gsb: ffffd001cc1af000   gss: 
      (XEN) [ 1993.145060] ds: 002b   es: 002b   fs: 0053   gs: 002b   ss: 0018 
  cs: 0010
    A triple fault is fatal to the domain under all circumstances (so will print
    at most once), and in practice is always an error condition rather than a
    reboot fallback.
    Reported-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit 677e64dbe315343620c3b266e9eb16623b118038
Author: Christian Lindig <christian.lindig@xxxxxxxxxx>
Date:   Wed Feb 27 10:33:42 2019 +0000

    tools/ocaml: Dup2 /dev/null to stdin in daemonize()
    Don't close stdin in daemonize() but dup2 /dev/null instead.  Otherwise, fd 0
    gets reused later:
      [root@idol ~]# ls -lav /proc/`pgrep xenstored`/fd
      total 0
      dr-x------ 2 root root  0 Feb 28 11:02 .
      dr-xr-xr-x 9 root root  0 Feb 27 15:59 ..
      lrwx------ 1 root root 64 Feb 28 11:02 0 -> /dev/xen/evtchn
      l-wx------ 1 root root 64 Feb 28 11:02 1 -> /dev/null
      l-wx------ 1 root root 64 Feb 28 11:02 2 -> /dev/null
      lrwx------ 1 root root 64 Feb 28 11:02 3 -> /dev/xen/privcmd
    Signed-off-by: Christian Lindig <christian.lindig@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>

commit 69f7643df68ef8e994221a996e336a47cbb7bbc8
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Mon Feb 11 13:31:02 2019 +0000

    x86/vmx: Properly flush the TLB when an altp2m is modified
    Modifications to an altp2m mark the p2m as needing flushing, but this was
    never wired up in the return-to-guest path.  As a result, stale TLB entries
    can remain after resuming the guest.
    In practice, this manifests as a missing EPT_VIOLATION or #VE exception when
    the guest subsequently accesses a page which has had its permissions 
    vmx_vmenter_helper() now has 11 p2ms to potentially invalidate, but issuing 
    INVEPT instructions isn't clever.  Instead, count how many contexts need
    invalidating, and use INVEPT_ALL_CONTEXT if two or more are in need of
    This doesn't have an XSA because altp2m is not yet a security-supported
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>

commit 0ec9b4ef3148e052bd8adf83800d7d681571f49e
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Thu Jan 17 12:26:17 2019 +0000

    x86/vmx: Fix security issue when a guest balloons out the #VE info page
    The logic in altp2m_vcpu_{en,dis}able_ve() and vmx_vcpu_update_vmfunc_ve() 
    dangerous.  After #VE has been set up, the guest can balloon out and free 
    nominated GFN, after which the processor may write to it.  Also, the 
    GFN query means the MFN is stale by the time it is used.  Alternatively, a
    guest can race two disable calls to cause one VMCS to still reference the
    nominated GFN after the tracking information was dropped.
    Rework the logic from scratch to make it safe.
    Hold an extra page reference on the underlying frame, to account for the
    VMCS's reference.  This means that if the GFN gets ballooned out, it isn't
    freed back to Xen until #VE is disabled, and the VMCS no longer refers to 
    A consequence of this is that altp2m_vcpu_disable_ve() needs to be called
    during the domain_kill() path, to drop the reference for domains which shut
    down with #VE still enabled.
    For domains using altp2m, we expect a single enable call and no disable for
    the remaining lifetime of the domain.  However, to avoid problems with
    concurrent calls, use cmpxchg() to locklessly maintain safety.
    This doesn't have an XSA because altp2m is not yet a security-supported
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Tested-by: Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>
    Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
    Release-acked-by: Juergen Gross <jgross@xxxxxxxx>
(qemu changes not included)

Xen-devel mailing list



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