|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable-smoke test] 129189: regressions - FAIL
flight 129189 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/129189/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 5 host-ping-check-native fail REGR. vs. 129151 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass version targeted for testing: xen f993c3e90728705dacd834b49a6e5608c1360409 baseline version: xen ce75973a273f6cacce2b2b8ace1d3ab4b304c361 Last test of basis 129151 2018-10-29 22:00:24 Z 0 days Testing same since 129189 2018-10-30 14:00:42 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxx> Kevin Tian <kevin.tian@xxxxxxxxx> jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-arm64-arm64-xl-xsm pass 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 f993c3e90728705dacd834b49a6e5608c1360409 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Tue Oct 30 11:17:00 2018 +0000 x86/pv: Fix crash when using `xl set-parameter pcid=...` "pcid=" is registered as a runtime parameter, which means that parse_pcid() must not reside in .init, or the following happens when parse_params() tries to call an unmapped function pointer. (XEN) ----[ Xen-4.12-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff82d080407fb3>] ffff82d080407fb3 (XEN) RFLAGS: 0000000000010292 CONTEXT: hypervisor (d0v1) (XEN) rax: ffff82d080407fb3 rbx: ffff82d0803cf270 rcx: 0000000000000000 (XEN) rdx: ffff8300abe67fff rsi: 000000000000000a rdi: ffff8300abe67bfd (XEN) rbp: ffff8300abe67ca8 rsp: ffff8300abe67ba0 r8: ffff83084d980000 (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: ffff8300abe67bfd r13: ffff82d0803cb628 r14: 0000000000000000 (XEN) r15: ffff8300abe67bf8 cr0: 0000000080050033 cr4: 0000000000172660 (XEN) cr3: 0000000828efd000 cr2: ffff82d080407fb3 (XEN) fsb: 00007fb810d4b780 gsb: ffff88007ce20000 gss: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 (XEN) Xen code around <ffff82d080407fb3> (ffff82d080407fb3) [fault on access]: (XEN) -- -- -- -- -- -- -- -- <--> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- (XEN) Xen stack trace from rsp=ffff8300abe67ba0: (XEN) ffff82d080217f61 ffff830826db0f09 ffff8300abe67bf8 ffff82d0803cf1e0 (XEN) 00007cff54198409 ffff8300abe67bf0 010001d000000000 0000000000000000 (XEN) ffff82d0803cf288 ffff8300abe67c88 ffff82d0805a09c0 616c620064696370 (XEN) 00000000aaaa0068 0000000000000296 ffff82d08023d60e aaaaaaaaaaaaaaaa (XEN) ffff83084d9b4000 ffff8300abe67c68 ffff82d08024940e ffff83083736e000 (XEN) 0000000000000080 000000000000007a 000000000000000a ffff82d08045e61c (XEN) ffff82d080573d80 ffff8300abe67cb8 ffff82d080249805 80000007fce54067 (XEN) fffffffffffffff2 ffff830826db0f00 ffff8300abfa7000 ffff82d08045e61c (XEN) ffff82d080573d80 ffff8300abe67cb8 ffff82d08021801e ffff8300abe67e48 (XEN) ffff82d08023f60a ffff83083736e000 0000000000000000 ffff8300abe67d58 (XEN) ffff82d080293d90 0000000000000092 ffff82d08023d60e ffff820040006ae0 (XEN) 0000000000000000 0000000000000000 00007fb810d5c010 ffff83083736e248 (XEN) 0000000000000286 ffff8300abe67d58 0000000000000000 ffff82e010521b00 (XEN) 0000000000000206 0000000000000000 0000000000000000 ffff8300abe67e48 (XEN) ffff82d080295270 00000000ffffffff ffff83083736e000 ffff8300abe67e48 (XEN) ffff820040006ae0 ffff8300abe67d98 000000120000001c 00007fb810d5d010 (XEN) 0000000000000009 0000000000000002 0000000000000001 00007fb810b53260 (XEN) 0000000000000001 0000000000000000 0000000000638bc0 00007fb81066a748 (XEN) 00007ffe11087881 0000000000000002 0000000000000001 00007fb810b53260 (XEN) 0000000000638b60 0000000000000000 00007fb8100322a0 ffff82d08035d444 (XEN) Xen call trace: (XEN) [<ffff82d080217f61>] kernel.c#parse_params+0x34a/0x3eb (XEN) [<ffff82d08021801e>] runtime_parse+0x1c/0x1e (XEN) [<ffff82d08023f60a>] do_sysctl+0x108d/0x1241 (XEN) [<ffff82d0803535cb>] pv_hypercall+0x1ac/0x4c5 (XEN) [<ffff82d08035d4a2>] lstar_enter+0x112/0x120 (XEN) (XEN) Pagetable walk from ffff82d080407fb3: (XEN) L4[0x105] = 00000000abe5c063 ffffffffffffffff (XEN) L3[0x142] = 00000000abe59063 ffffffffffffffff (XEN) L2[0x002] = 000000084d9bf063 ffffffffffffffff (XEN) L1[0x007] = 0000000000000000 ffffffffffffffff (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) FATAL PAGE FAULT (XEN) [error_code=0010] (XEN) Faulting linear address: ffff82d080407fb3 (XEN) **************************************** Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> commit c238ea3f4caccf36ab1a559f958cbe5192327f6a Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Oct 25 14:11:58 2018 +0100 x86/vvmx: Don't handle unknown nested vmexit reasons at L0 This is very dangerous from a security point of view, because a missing entry will cause L2's action to be interpreted as L1's action. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> commit 307ee30a1429e2f45d505c1299b58090edd81eb0 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Oct 25 15:17:50 2018 +0100 x86/vvmx: Drop the now-obsolete vmx_inst_check_privilege() Now that nvmx_handle_vmx_insn() performs all VT-x instruction checks, there is no need for redundant checking in vmx_inst_check_privilege(). Remove it, and take out the vmxon_check boolean which was plumbed through decode_vmx_inst(). Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> commit 18cef4df8f8bd04a59a218e5f67e7896e43fd07d Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Oct 25 14:40:11 2018 +0100 x86/vvmx: Unconditionally initialise vmxon_region_pa during vcpu construction This is a stopgap solution until the toolstack side of initialisation can be sorted out, but it does result in the nvmx_vcpu_in_vmx() predicate working correctly even when nested virt hasn't been enabled for the domain. Update nvmx_handle_vmx_insn() to include the in-vmx mode check (for all instructions other than VMXON) to complete the set of #UD checks. In addition, sanity check that the nested vmexit handler has worked correctly, and that we are only providing emulation of the VT-x instructions to L1 guests. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> commit 6faff8f9005d685185cd3f4ed116bf45d7d1553f Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Thu Oct 25 14:08:33 2018 +0100 x86/vvmx: Let L1 handle all the unconditional vmexit instructions Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Sergey Dyasli <sergey.dyasli@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> commit 30f43f4aa81e2dea6f754dddaf794518587022c2 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon May 28 15:22:49 2018 +0100 x86: Reorganise and rename debug register fields in struct vcpu Reusing debugreg[5] for the PV emulated IO breakpoint information is confusing to read. Instead, introduce a dr7_emul field in pv_vcpu for the purpose. With the PV emulation out of the way, debugreg[4,5] are entirely unused and don't need to be stored. Rename debugreg[0..3] to dr[0..3] to reduce code volume, but keep them as an array because their behaviour is identical and this helps simplfy some of the PV handling. Introduce dr6 and dr7 fields to replace debugreg[6,7] which removes the storage for debugreg[4,5]. In arch_get_info_guest(), handle the merging of emulated dr7 state alongside all other dr handling, rather than much later. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> commit 2b3218eb6bf27d3b66885dde8ae05e4e7864370d Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon May 28 15:16:37 2018 +0000 x86/emul: Unfold %cr4.de handling in x86emul_read_dr() No functional change (as curr->arch.debugreg[5] is zero when DE is clear), but this change simplifies the following patch. Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx> commit 0a1fa635029d100d4b6b7eddb31d49603217cab7 Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Date: Mon Oct 29 11:29:54 2018 +0000 x86/domain: Fix build with GCC 4.3.x GCC 4.3.x can't initialise the user_regs structure like this. Reported-by: Jan Beulich <JBeulich@xxxxxxxx> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Reviewed-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Jan Beulich <jbeulich@xxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |