This run is configured for baseline tests only.
flight 72355 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72355/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl 1 build-check(1) blocked n/a
build-arm64-libvirt 1 build-check(1) blocked n/a
test-arm64-arm64-xl-credit2 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-xsm 2 hosts-allocate broken never pass
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops 2 hosts-allocate broken never pass
build-arm64-xsm 3 capture-logs broken never pass
build-arm64 3 capture-logs broken never pass
build-arm64-pvops 3 capture-logs broken never pass
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail blocked
in 72337
test-amd64-i386-freebsd10-amd64 11 guest-start fail like 72337
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl-midway 13 migrate-support-check fail never pass
test-armhf-armhf-xl-midway 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-amd 12 guest-start fail never pass
test-armhf-armhf-xl-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 15 guest-saverestore fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check
fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check
fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-qemuu-nested-intel 18 capture-logs/l1(18) fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass
version targeted for testing:
xen 830224431b67fd2afad9bdc532dc1bede20032d5
baseline version:
xen df0949d197cc753871f5df1a0358b43edd2fd365
Last test of basis 72337 2017-10-21 04:15:02 Z 5 days
Testing same since 72355 2017-10-26 09:18:07 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.coop...@citrix.com>
Jan Beulich <jbeul...@suse.com>
Kevin Tian <kevin.t...@intel.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm broken
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-arm64 broken
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt blocked
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-arm64-pvops broken
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun pass
build-i386-rumprun pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl blocked
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm blocked
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm blocked
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 fail
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 blocked
test-armhf-armhf-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 pass
test-amd64-amd64-xl-qemut-win10-i386 fail
test-amd64-i386-xl-qemut-win10-i386 fail
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-armhf-armhf-xl-midway pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images
Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
broken-step build-arm64-xsm hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-xsm capture-logs
broken-step build-arm64 capture-logs
broken-step build-arm64-pvops capture-logs
Push not applicable.
------------------------------------------------------------
commit 830224431b67fd2afad9bdc532dc1bede20032d5
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Oct 24 16:50:14 2017 +0200
x86emul: handle address wrapping
This just the emulator part of commit 7869e2bafe
("x86emul/fuzz: add rudimentary limit checking"):
Several adjustments to the emulator's address calculations are needed:
While the DstBitBase one is really mandatory, the specification allows
for either original or new behavior for two-part accesses. Observed
behavior on real hardware, however, is for such accesses to silently
wrap at the 2^^32 boundary in other than 64-bit mode, just like they do
at the 2^^64 boundary in 64-bit mode, which our code is now being
brought in line with. While adding truncate_ea() invocations there,
also convert open coded instances of it.
Reported-by: George Dunlap <george.dun...@citrix.com>
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: George Dunlap <george.dun...@citrix.com>
Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
commit 6e36296c6c38fa735cb91650c443fb096ac0a79d
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Oct 24 16:49:44 2017 +0200
VMX: PLATFORM_INFO MSR is r/o
Therefore all write attempts should produce #GP, just like on real
hardware.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Roger Pau Monné <roger....@citrix.com>
Acked-by: Kevin Tian <kevin.t...@intel.com>
commit 5805ab112bd9d509efcc6aa24c52085c5eb7ef71
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Oct 24 16:48:50 2017 +0200
x86: avoid #GP for PV guest MSR accesses
Halfway recent Linux kernels probe MISC_FEATURES_ENABLES on all CPUs,
leading to ugly recovered #GP fault messages with debug builds on older
systems. We can do better, so introduce synthetic feature flags for
both this and PLATFORM_INFO to avoid the rdmsr_safe() altogether.
Note that the r/o nature of PLATFORM_INFO is now also being enforced.
The rdmsr_safe() uses for MISC_ENABLE are left in place as benign - it
exists for all 64-bit capable Intel CPUs (see e.g. early_init_intel()).
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
commit bc37a36ab1bcd879740523515615f61ba2bde6c0
Author: Andrew Cooper <andrew.coop...@citrix.com>
Date: Tue Oct 24 16:43:43 2017 +0200
x86/vvmx: Fix WRMSR interception of VMX MSRs
FEATURE_CONTROL is already read with LOCK bit set (so is unmodifiable), and
all VMX MSRs are read-only. Also, fix the MSR_IA32_VMX_TRUE_ENTRY_CTLS
bound
to be MSR_IA32_VMX_VMFUNC, rather than having the intervening MSRs falling
into the default case.
Raise #GP faults if the guest tries to modify any of them.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Kevin Tian <kevin.t...@intel.com>
master commit: 46c3acb308bf0cd044b114e637aacaf18b957618
master date: 2017-06-30 11:27:50 +0100
commit cf451a8253e0c685d4713543a8033193568df763
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Oct 24 16:43:08 2017 +0200
x86: fix do_update_va_mapping_otherdomain() wrt translated domains
While I can't seem to find any users of this hypercall (being a likely
explanation of why the problem wasn't noticed so far), just like for
do_mmu_update() paged-out and shared page handling is needed here. Move
all this logic into mod_l1_entry(), which then also results in no
longer
- doing any of this handling for non-present PTEs,
- acquiring two temporary page references when one is already more than
enough.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
master commit: 46aaf41ee099a048d7a554c03ae01bcdaa07f776
master date: 2017-10-13 12:43:41 +0200
commit 24955c3143f2b07178d648951147fcd974bd0e37
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Oct 24 16:42:39 2017 +0200
x86: request page table page-in for the correct domain
The domain passed to p2m_mem_paging_populate() should match the one
passed to the corresponding get_page_from_gfn().
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
master commit: 66b7f58e585e39fb19bbf38df02fff5a80eba1ff
master date: 2017-10-13 12:42:43 +0200
commit 46d90a78f6439da8ae175691762033885866209e
Author: Andrew Cooper <andrew.coop...@citrix.com>
Date: Tue Oct 24 16:42:13 2017 +0200
xen/domctl: Fix Xen heap leak via XEN_DOMCTL_getvcpucontext
The backing structure for XEN_DOMCTL_getvcpucontext is only zeroed in the
x86
HVM case. At the very least, this means that ARM returns junk through its
flags field (as it is only ever conditionally or'd into), and x86 PV leaks
data through gdt_frames[14...15]. (An exhaustive search for other leaks
hasn't been performed).
Unconditionally zero the memory upon allocation, and forgo the double clear
for x86 HVM. These hypercalls are not on hotpaths.
Note that this does not qualify for an XSA. Per XSA-77,
XEN_DOMCTL_getvcpucontext is unsafe for disaggregation, meaning that only
the
control domain can use this hypercall.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
master commit: 3b2eeb7412e529f38d1e8b872ba0bc6ab09a7008
master date: 2017-10-09 12:43:21 +0100
commit cd9ee1f72d46056006da3d695c81be5584922ad4
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Oct 24 16:41:40 2017 +0200
x86/PV: fix/generalize guest nul selector handling
Segment bases (and limits) aren't being cleared by the loading of a nul
selector into a segment register on AMD CPUs. Therefore, if an
outgoing vCPU has a non-zero base in FS or GS and the subsequent
incoming vCPU has a non-zero but nul selector in the respective
register(s), the selector value(s) would be loaded without clearing the
segment base(s) in the hidden register portion.
Since the ABI states "zero" in its description of the fs and gs fields,
it is worth noting that the chosen approach to fix this alters the
written down ABI. I consider this preferrable over enforcing the
previously written down behavior, as nul selectors are far more likely
to be what was meant from the beginning.
The adjustments also eliminate an inconsistency between FS and GS
handling: Old code had an extra pointless (gs_base_user was always zero
when DIRTY_GS was set) conditional for GS. The old bitkeeper changeset
has no explanation for this asymmetry.
Inspired by Linux commit e137a4d8f4dd2e277e355495b6b2cb241a8693c3.
Additionally for DS and ES a flat selector is being loaded prior to the
loading of a nul one on AMD CPUs, just as a precautionary measure
(we're not currently aware of ways for a guest to deduce the base of a
segment register which has a nul selector loaded).
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
master commit: 4e383df8650d72e47e2ca4ebfc4f6986f791d2f2
master date: 2017-10-04 14:17:08 +0200
commit 2e24a9ed72720e0f3ec9bc92b92240915f46e7b7
Author: Andrew Cooper <andrew.coop...@citrix.com>
Date: Tue Oct 24 16:40:56 2017 +0200
x86/msr: Correct the definition of MSR_IA32_APICBASE_BASE
0xfffff << 12 is undefined behaviour, due to shifting into the sign bit of
an
integer.
Spotted by the Undefined Behaviour Sanitiser
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Wei Liu <wei.l...@citrix.com>
master commit: dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
master date: 2017-10-03 17:45:24 +0100
commit d0500f203285fe3d12b83a837b21930e4bac69da
Author: Andrew Cooper <andrew.coop...@citrix.com>
Date: Tue Oct 24 16:40:23 2017 +0200
x86/svm: Fix a livelock when trying to run shadowed unpaged guests
On AMD processors which support SMEP (Some Fam16h processors) and SMAP (Zen,
Fam17h), a guest which is running with shadow paging and clears CR0.PG while
keeping CR4.{SMEP,SMAP} set will livelock, as hardware raises #PF which the
shadow pagetable concludes shouldn't happen.
This occurs because hardware is running with host paging settings, which
causes the guests choice of SMEP/SMAP to actually take effect, even though
they shouldn't from the guests point of view.
Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
master commit: 3164f2f9db1e63ea64c3f9520d40cb09920d2b35
master date: 2017-10-02 13:57:34 +0100
commit f03b9e86e7e18cbbc0b9ecb01ae74730362c6603
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Oct 24 16:39:33 2017 +0200
gnttab: fix pin count / page reference race
Dropping page references before decrementing pin counts is a bad idea
if assumptions are being made that a non-zero pin count implies a valid
page. Fix the order of operations in gnttab_copy_release_buf(), but at
the same time also remove the assertion that was found to trigger:
map_grant_ref() also has the potential of causing a race here, and
changing the order of operations there would likely be quite a bit more
involved.
This is CVE-2017-15597 / XSA-236.
Reported-by: Pawel Wieczorkiewicz <wipa...@amazon.de>
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
master commit: e008f7619dcd6d549727c9635b3f9f3c7ee483ed
master date: 2017-10-24 16:01:33 +0200
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
