From mboxrd@z Thu Jan 1 00:00:00 1970 From: osstest service owner Subject: [xen-unstable-smoke test] 79969: regressions - FAIL Date: Tue, 02 Feb 2016 15:51:32 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xensource.com, osstest-admin@xenproject.org List-Id: xen-devel@lists.xenproject.org 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 Andrew Cooper David Vrabel Juergen Gross Kevin Tian 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 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 Tested-by: Alan.Robinson Reviewed-by: Dario Faggioli commit f2c96ac4dedf4976e46de34c69c2cd8b289c4ef2 Author: Juergen Gross 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 Reviewed-by: Dario Faggioli commit 949fea109e5f51bb9cbf5f283eb9fac26186dfac Author: Andrew Cooper 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) [] spinlock.c#check_lock+0x1e/0x40 (XEN) [] _spin_lock+0x11/0x52 (XEN) [] vpt.c#pt_lock+0x24/0x40 (XEN) [] destroy_periodic_time+0x18/0x81 (XEN) [] rtc_deinit+0x53/0x78 (XEN) [] hvm_domain_destroy+0x52/0x69 (XEN) [] arch_domain_destroy+0x1a/0x98 (XEN) [] domain.c#complete_domain_destroy+0x6f/0x182 (XEN) [] rcupdate.c#rcu_process_callbacks+0x144/0x1a6 (XEN) [] softirq.c#__do_softirq+0x82/0x8d (XEN) [] do_softirq+0x13/0x15 (XEN) [] 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 Reviewed-by: Jan Beulich commit b6171b7b9fe1666bc5eae38bc5e992c2c233c43d Author: David Vrabel 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 Reviewed-by: Andrew Cooper commit 7d7918e28bd644490e8bff7003e6abf78f33031a Author: Andrew Cooper 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 Reviewed-by: Boris Ostrovsky Reviewed-by: Jan Beulich Acked-by: Kevin Tian commit 78c93adf0a7f6a7abe249a63e7398ca1221a6d25 Author: Andrew Cooper 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 Reviewed-by: Jan Beulich Acked-by: Kevin Tian (qemu changes not included)