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.robin...@ts.fujitsu.com>
Andrew Cooper <andrew.coop...@citrix.com>
David Vrabel <david.vra...@citrix.com>
Juergen Gross <jgr...@suse.com>
Kevin Tian <kevin.t...@intel.com>
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 <jgr...@suse.com>
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 <jgr...@suse.com>
Tested-by: Alan.Robinson <alan.robin...@ts.fujitsu.com>
Reviewed-by: Dario Faggioli <dario.faggi...@citrix.com>
commit f2c96ac4dedf4976e46de34c69c2cd8b289c4ef2
Author: Juergen Gross <jgr...@suse.com>
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 <jgr...@suse.com>
Reviewed-by: Dario Faggioli <dario.faggi...@citrix.com>
commit 949fea109e5f51bb9cbf5f283eb9fac26186dfac
Author: Andrew Cooper <andrew.coop...@citrix.com>
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.coop...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
commit b6171b7b9fe1666bc5eae38bc5e992c2c233c43d
Author: David Vrabel <david.vra...@citrix.com>
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.vra...@citrix.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
commit 7d7918e28bd644490e8bff7003e6abf78f33031a
Author: Andrew Cooper <andrew.coop...@citrix.com>
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.coop...@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Kevin Tian <kevin.t...@intel.com>
commit 78c93adf0a7f6a7abe249a63e7398ca1221a6d25
Author: Andrew Cooper <andrew.coop...@citrix.com>
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.coop...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Kevin Tian <kevin.t...@intel.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
