* [xen-unstable-smoke test] 129189: regressions - FAIL
@ 2018-10-30 16:05 osstest service owner
0 siblings, 0 replies; only message in thread
From: osstest service owner @ 2018-10-30 16:05 UTC (permalink / raw)
To: xen-devel, osstest-admin
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@citrix.com>
Jan Beulich <jbeulich@suse.com>
Kevin Tian <kevin.tian@intel.com>
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@citrix.com>
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@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit c238ea3f4caccf36ab1a559f958cbe5192327f6a
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
commit 307ee30a1429e2f45d505c1299b58090edd81eb0
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
commit 18cef4df8f8bd04a59a218e5f67e7896e43fd07d
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
commit 6faff8f9005d685185cd3f4ed116bf45d7d1553f
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
Reviewed-by: Sergey Dyasli <sergey.dyasli@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
commit 30f43f4aa81e2dea6f754dddaf794518587022c2
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
commit 2b3218eb6bf27d3b66885dde8ae05e4e7864370d
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
commit 0a1fa635029d100d4b6b7eddb31d49603217cab7
Author: Andrew Cooper <andrew.cooper3@citrix.com>
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@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2018-10-30 16:06 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-30 16:05 [xen-unstable-smoke test] 129189: regressions - FAIL osstest service owner
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.