|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-4.6-testing test] 105673: regressions - FAIL
flight 105673 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105673/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 104585 Tests which are failing intermittently (not blocking): test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail in 105664 pass in 105673 test-amd64-amd64-pair 20 guest-start/debian fail pass in 105664 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail blocked in 104585 test-armhf-armhf-libvirt 13 saverestore-support-check fail like 104585 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 104585 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104585 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 104585 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104585 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 104585 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail like 104585 Tests which did not succeed, but are not blocking: test-xtf-amd64-amd64-5 62 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-4 62 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-2 62 xtf/test-pv32pae-xsa-194 fail never pass test-xtf-amd64-amd64-1 62 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass test-xtf-amd64-amd64-3 62 xtf/test-pv32pae-xsa-194 fail never pass test-amd64-amd64-libvirt 12 migrate-support-check fail never pass test-amd64-i386-libvirt 12 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-libvirt 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail never pass test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass test-armhf-armhf-xl 12 migrate-support-check fail never pass test-armhf-armhf-xl 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-check fail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass version targeted for testing: xen 576f319a804bce8c9a7fb70a042f873f5eaf0151 baseline version: xen 09f521a077024d5955d766eef7a040d2af928ec2 Last test of basis 104585 2017-01-22 08:19:51 Z 18 days Testing same since 105664 2017-02-09 10:14:26 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: George Dunlap <george.dunlap@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Joao Martins <joao.m.martins@xxxxxxxxxx> jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64-xtf pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-prev pass build-i386-prev pass build-amd64-pvops pass 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-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-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass 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 pass 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-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 fail test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumprun-i386 pass test-amd64-amd64-qemuu-nested-intel pass 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-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 fail 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 fail test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-libvirt-vhd pass test-armhf-armhf-xl-vhd pass test-amd64-amd64-xl-qemut-winxpsp3 pass test-amd64-i386-xl-qemut-winxpsp3 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3 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 576f319a804bce8c9a7fb70a042f873f5eaf0151 Author: George Dunlap <george.dunlap@xxxxxxxxxx> Date: Thu Feb 9 10:37:08 2017 +0100 x86/emulate: don't assume that addr_size == 32 implies protected mode Callers of x86_emulate() generally define addr_size based on the code segment. In vm86 mode, the code segment is set by the hardware to be 16-bits; but it is entirely possible to enable protected mode, set the CS to 32-bits, and then disable protected mode. (This is commonly called "unreal mode".) But the instruction decoder only checks for protected mode when addr_size == 16. So in unreal mode, hardware will throw a #UD for VEX prefixes, but our instruction decoder will decode them, triggering an ASSERT() further on in _get_fpu(). (With debug=n the emulator will incorrectly emulate the instruction rather than throwing a #UD, but this is only a bug, not a crash, so it's not a security issue.) Teach the instruction decoder to check that we're in protected mode, even if addr_size is 32. Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx> Split real mode and VM86 mode handling, as VM86 mode is strictly 16-bit at all times. Re-base. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 05118b1596ffe4559549edbb28bd0124a7316123 master date: 2017-01-25 15:09:55 +0100 commit 163543ac31e90bdc7da589c63c5a997004ee11c9 Author: Joao Martins <joao.m.martins@xxxxxxxxxx> Date: Thu Feb 9 10:35:58 2017 +0100 x86/hvm: do not set msr_tsc_adjust on hvm_set_guest_tsc_fixed Commit 6e03363 ("x86: Implement TSC adjust feature for HVM guest") implemented TSC_ADJUST MSR for hvm guests. Though while booting an HVM guest the boot CPU would have a value set with delta_tsc - guest tsc while secondary CPUS would have 0. For example one can observe: $ xen-hvmctx 17 | grep tsc_adjust TSC_ADJUST: tsc_adjust ff9377dfef47fe66 TSC_ADJUST: tsc_adjust 0 TSC_ADJUST: tsc_adjust 0 TSC_ADJUST: tsc_adjust 0 Upcoming Linux 4.10 now validates whether this MSR is correct and adjusts them accordingly under the following conditions: values of < 0 (our case for CPU 0) or != 0 or values > 7FFFFFFF. In this conditions it will force set to 0 and for the CPUs that the value doesn't match all together. If this msr is not correct we would see messages such as: [Firmware Bug]: TSC ADJUST: CPU0: -30517044286984129 force to 0 And on HVM guests supporting TSC_ADJUST (requiring at least Haswell Intel) it won't boot. Our current vCPU 0 values are incorrect and according to Intel SDM which on section "Time-Stamp Counter Adjustment" states that "On RESET, the value of the IA32_TSC_ADJUST MSR is 0." hence we should set it 0 and be consistent across multiple vCPUs. Perhaps this MSR should be only changed by the guest which already happens through hvm_set_guest_tsc_adjust(..) routines (see below). After this patch guests running Linux 4.10 will see a valid IA32_TSC_ADJUST msr of value 0 for all CPUs and are able to boot. On the same section of the spec ("Time-Stamp Counter Adjustment") it is also stated: "If an execution of WRMSR to the IA32_TIME_STAMP_COUNTER MSR adds (or subtracts) value X from the TSC, the logical processor also adds (or subtracts) value X from the IA32_TSC_ADJUST MSR. Unlike the TSC, the value of the IA32_TSC_ADJUST MSR changes only in response to WRMSR (either to the MSR itself, or to the IA32_TIME_STAMP_COUNTER MSR). Its value does not otherwise change as time elapses. Software seeking to adjust the TSC can do so by using WRMSR to write the same value to the IA32_TSC_ADJUST MSR on each logical processor." This suggests these MSRs values should only be changed through guest i.e. throught write intercept msrs. We keep IA32_TSC MSR logic such that writes accomodate adjustments to TSC_ADJUST, hence no functional change in the msr_tsc_adjust for IA32_TSC msr. Though, we do that in a separate routine namely hvm_set_guest_tsc_msr instead of through hvm_set_guest_tsc(...). Signed-off-by: Joao Martins <joao.m.martins@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> master commit: 98297f09bd07bb63407909aae1d309d8adeb572e master date: 2017-01-24 12:37:36 +0100 commit 5c38a2e73623ebc7f51b62a7bf5293e748d1b623 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Feb 9 10:35:24 2017 +0100 x86: segment attribute handling adjustments Null selector loads into SS (possible in 64-bit mode only, and only in rings other than ring 3) must not alter SS.DPL. (This was found to be an issue on KVM, and fixed in Linux commit 33ab91103b.) Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 366ff5f1b3252f9069d5aedb2ffc2567bb0a37c9 master date: 2017-01-20 14:39:12 +0100 commit d3630ca700a59d239fb1299b8e0599db647b5011 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Feb 9 10:35:02 2017 +0100 x86emul: LOCK check adjustments BT, being encoded as DstBitBase just like BT{C,R,S}, nevertheless does not write its (register or memory) operand and hence also doesn't allow a LOCK prefix to be used. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: f2d4f4ba80de8a03a1b0f300d271715a88a8433d master date: 2017-01-20 14:37:33 +0100 commit ae0263091cb6c1f20b87a3dea40c4c6a4ba47aa9 Author: Jan Beulich <jbeulich@xxxxxxxx> Date: Thu Feb 9 10:34:28 2017 +0100 x86emul: VEX.B is ignored in compatibility mode While VEX.R and VEX.X are guaranteed to be 1 in compatibility mode (and hence a respective mode_64bit() check can be dropped), VEX.B can be encoded as zero, but would be ignored by the processor. Since we emulate instructions in 64-bit mode (except possibly in the test harness), we need to force the bit to 1 in order to not act on the wrong {X,Y,Z}MM register (which has no bad effect on 32-bit test harness builds, as there the bit would again be ignored by the hardware, and would by default be expected to be 1 anyway). We must not, however, fiddle with the high bit of VEX.VVVV in the decode phase, as that would undermine the checking of instructions requiring the field to be all ones independent of mode. This is being enforced in copy_REX_VEX() instead. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> x86emul: correct VEX/XOP/EVEX operand size handling for 16-bit code Operand size defaults to 32 bits in that case, but would not have been set that way in the absence of an operand size override. Reported-by: Wei Liu <wei.liu2@xxxxxxxxxx> (by AFL fuzzing) Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> master commit: 89c76ee7f60777b81c8fd0475a6af7c84e72a791 master date: 2017-01-17 10:32:25 +0100 master commit: beb82042447c5d6e7073d816d6afc25c5a423cde master date: 2017-01-25 15:08:59 +0100 (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |