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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           6 xen-boot                  fail REGR. vs. 79786

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     12 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  ffc342fbb060cd753fc3a5f6fb6f550dd29a2637
baseline version:
 xen                  428607a410e8abfb4bb71195d74cd1157e3d06ae

Last test of basis    79786  2016-02-01 14:03:08 Z    1 days
Testing same since    79969  2016-02-02 14:01:30 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Alan.Robinson <alan.robinson@xxxxxxxxxxxxxx>
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  David Vrabel <david.vrabel@xxxxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Kevin Tian <kevin.tian@xxxxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          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 ffc342fbb060cd753fc3a5f6fb6f550dd29a2637
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Tue Feb 2 14:03:40 2016 +0100

    credit: recalculate per-cpupool credits when updating timeslice
    
    When modifying the timeslice of the credit scheduler in a cpupool the
    cpupool global credit value (n_cpus * credits_per_tslice) isn't
    recalculated. This will lead to wrong scheduling decisions later.
    
    Do the recalculation when updating the timeslice.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Tested-by: Alan.Robinson <alan.robinson@xxxxxxxxxxxxxx>
    Reviewed-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>

commit f2c96ac4dedf4976e46de34c69c2cd8b289c4ef2
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Tue Feb 2 14:03:06 2016 +0100

    credit: update timeslice under lock
    
    When updating the timeslice of the credit scheduler protect the
    scheduler's private data by it's lock. Today a possible race could
    result only in some weird scheduling decisions during one timeslice,
    but further adjustments will need the lock anyway.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>

commit 949fea109e5f51bb9cbf5f283eb9fac26186dfac
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Feb 2 14:02:37 2016 +0100

    x86/hvm: fix use-after-free introduced by c/s 428607a
    
    c/s 428607a "x86: shrink 'struct domain', was already PAGE_SIZE" introduced 
a
    use-after-free error during domain destruction, because of the order in 
which
    timers are torn down.
    
      (XEN) Xen call trace:
      (XEN)    [<ffff82d08013344e>] spinlock.c#check_lock+0x1e/0x40
      (XEN)    [<ffff82d08013349b>] _spin_lock+0x11/0x52
      (XEN)    [<ffff82d0801e8076>] vpt.c#pt_lock+0x24/0x40
      (XEN)    [<ffff82d0801e88f4>] destroy_periodic_time+0x18/0x81
      (XEN)    [<ffff82d0801e1089>] rtc_deinit+0x53/0x78
      (XEN)    [<ffff82d0801d1e5a>] hvm_domain_destroy+0x52/0x69
      (XEN)    [<ffff82d08016a758>] arch_domain_destroy+0x1a/0x98
      (XEN)    [<ffff82d080107cd5>] domain.c#complete_domain_destroy+0x6f/0x182
      (XEN)    [<ffff82d080126a19>] rcupdate.c#rcu_process_callbacks+0x144/0x1a6
      (XEN)    [<ffff82d080132c52>] softirq.c#__do_softirq+0x82/0x8d
      (XEN)    [<ffff82d080132caa>] do_softirq+0x13/0x15
      (XEN)    [<ffff82d080248ae1>] entry.o#process_softirqs+0x21/0x30
      (XEN)
      (XEN)
      (XEN) ****************************************
      (XEN) Panic on CPU 3:
      (XEN) GENERAL PROTECTION FAULT
      (XEN) [error_code=0000]
      (XEN) ****************************************
    
    Defer the freeing of d->arch.hvm_domain.pl_time until all timers have been
    destroyed.
    
    For safety, NULL out the pointers after freeing them, in an attempt to make
    mistakes more obvious in the future.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit b6171b7b9fe1666bc5eae38bc5e992c2c233c43d
Author: David Vrabel <david.vrabel@xxxxxxxxxx>
Date:   Tue Feb 2 14:01:57 2016 +0100

    x86: only check for two watchdog NMIs
    
    Since the NMI handler can now recognize watchdog NMIs, make
    check_nmi_watchdog() only check for at least two watchdog NMIs.  This
    prevents false negatives caused by other processors (which may be
    being power managed by the BIOS) running at reduced clock frequencies.
    
    We check for more than one NMI since there are apparently systems
    where the NMI works only once.
    
    This will also slightly speed up boot times since we only wait the
    full 10 ticks if the NMI watchdog on one or more CPUs is not working.
    
    Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 7d7918e28bd644490e8bff7003e6abf78f33031a
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Feb 2 14:01:29 2016 +0100

    x86/hvm: don't intercept #UD exceptions in general
    
    c/s 0f1cb96e "x86 hvm: Allow cross-vendor migration" caused HVM domains to
    unconditionally intercept #UD exceptions.  While cross-vendor migration is
    cool as a demo, it is extremely niche.
    
    Intercepting #UD allows userspace code in a multi-vcpu guest to execute
    arbitrary instructions in the x86 emulator by having one thread execute a 
ud2a
    instruction, and having a second thread rewrite the instruction before the
    emulator performs an instruction fetch.
    
    XSAs 105, 106 and 110 are all examples where guest userspace can use bugs in
    the x86 emulator to compromise security of the domain, either by privilege
    escalation or causing a crash.
    
    c/s 2d67a7a4 "x86: synchronize PCI config space access decoding"
    introduced (amongst other things) a per-domain vendor, based on the guests
    cpuid policy.
    
    Use the per-guest vendor to enable #UD interception only when a domain is
    configured for a vendor different to the current hardware.  (#UD 
interception
    is also enabled if hvm_fep is specified on the Xen command line.  This is a
    debug-only option whose entire purpose is for testing the x86 emulator.)
    
    As a result, the overwhelming majority of usecases now have #UD interception
    disabled, removing an attack surface for malicious guest userspace.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>

commit 78c93adf0a7f6a7abe249a63e7398ca1221a6d25
Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
Date:   Tue Feb 2 14:00:52 2016 +0100

    x86/vmx: don't clobber exception_bitmap when entering/leaving emulated real 
mode
    
    Most updates to the exception bitmaps set or clear an individual bits.
    
    However, entering or exiting emulated real mode unilaterally clobbers it,
    leaving the exit code to recalculate what it should have been.  This is 
error
    prone, and indeed currently fails to recalculate the TRAP_no_device 
intercept
    appropriately.
    
    Instead of overwriting exception_bitmap when entering emulated real mode, 
move
    the override into vmx_update_exception_bitmap() and leave exception_bitmap
    unmodified.
    
    This means that recalculation is unnecessary, and that the use of
    vmx_fpu_leave() and vmx_update_debug_state() while in emulated real mode
    doesn't result in TRAP_no_device and TRAP_int3 being un-intercepted.
    
    This is only a functional change on hardware lacking unrestricted guest
    support.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
(qemu changes not included)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel