* [xen-unstable test] 106435: regressions - FAIL
@ 2017-03-04 15:19 osstest service owner
2017-03-04 15:44 ` Andrew Cooper
0 siblings, 1 reply; 4+ messages in thread
From: osstest service owner @ 2017-03-04 15:19 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 106435 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 106412
test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 106412
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 106412
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106412
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106412
test-armhf-armhf-libvirt 13 saverestore-support-check fail like 106412
test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail like 106412
test-amd64-amd64-xl-rtds 9 debian-install fail like 106412
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-libvirt-qcow2 1 build-check(1) blocked n/a
test-arm64-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-rtds 1 build-check(1) blocked n/a
test-arm64-arm64-xl-multivcpu 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
build-arm64 5 xen-build fail never pass
build-arm64-xsm 5 xen-build fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
build-arm64-pvops 5 kernel-build 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-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-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-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 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-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-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-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
version targeted for testing:
xen 6d55c0c316357a412526b9dccd45d3c3abb75227
baseline version:
xen b151125b4d89d7ec139ac34470e3c709fb4b1b4d
Last test of basis 106412 2017-03-03 16:45:21 Z 0 days
Testing same since 106435 2017-03-04 04:40:30 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Chao Gao <chao.gao@intel.com>
Feng Wu <feng.wu@intel.com>
Jan Beulich <jbeulich@suse.com>
Kevin Tian <kevin.tian@intel.com>
Olaf Hering <olaf@aepfle.de>
Sander Eikelenboom <linux@eikelenboom.it>
Stefano Stabellini <sstabellini@kernel.org>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm fail
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-arm64 fail
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt blocked
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-arm64-pvops fail
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 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-arm64-arm64-xl-credit2 blocked
test-armhf-armhf-xl-credit2 pass
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-arm64-arm64-libvirt blocked
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-arm64-arm64-xl-multivcpu blocked
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-arm64-arm64-libvirt-qcow2 blocked
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-arm64-arm64-xl-rtds blocked
test-armhf-armhf-xl-rtds pass
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 6d55c0c316357a412526b9dccd45d3c3abb75227
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu Mar 2 19:58:20 2017 +0000
x86/cpuid: Fix booting on AMD Phenom 6-core platform
c/s 5cecf60f4 "x86/cpuid: Handle leaf 0x1 in guest_cpuid()" causes Linux 4.10
to crash during boot.
It turns out to be because of the reported apic_id, which was altered to be
more consistent across guests. Revert back to the previous behaviour, by
limiting the apic_id adjustment to HVM guests only. Whomever gets to fixes
topology representation is going to have a lot of fun with non-power-of-2 AMD
boxes.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
commit 9d686d1269faea0447f48ed2ce789c4a06756e07
Author: Olaf Hering <olaf@aepfle.de>
Date: Fri Mar 3 08:52:09 2017 +0000
tools/xenstore: define off_t
talloc.h uses off_t, but did not include <sys/types.h>.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Wei Liu <wei.liu2@citrix.com>
commit 56ac30f92bddc23f356d779d8c7478dabe5839e7
Author: Stefano Stabellini <sstabellini@kernel.org>
Date: Wed Mar 1 11:43:15 2017 -0800
xen/arm: introduce vwfi parameter
Introduce new Xen command line parameter called "vwfi", which stands for
virtual wfi. The default is "trap": Xen traps guest wfi and wfe
instructions. In the case of wfi, Xen calls vcpu_block on the guest
vcpu; in the case of guest wfe, Xen calls vcpu_yield on the guest vcpu.
The behavior can be changed by setting vwfi to "native", in that case
Xen doesn't trap neither wfi nor wfe, running them in guest context.
The result is strong reduction in irq latency (from 5000ns to 2000ns,
measured using https://github.com/edgarigl/tbm, the physical timer, and
1 pcpu dedicated to 1 vcpu). The downside is that the scheduler thinks
that the guest is busy when actually is sleeping, leading to suboptimal
scheduling decisions.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
commit f2c608444261824a9463a7847be2d08ee3ae0c48
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 3 17:08:36 2017 +0100
x86/SVM: correct boot time cpu_data[] handling
start_svm() already runs after cpu_data[] was set up, so it shouldn't
modify it anymore (at least not directly). Constify the involved
pointers.
Furthermore LMSLE feature detection was broken by 566ddbe833 ("x86:
Fail CPU bringup cleanly if it cannot initialise HVM"), as Andrew
Cooper has pointed out: c couldn't possibly equal &boot_cpu_data
anymore. (But since it's unsafe migration-wise for some more time,
suppress the feature actually being enabled for us.)
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
commit 3c76488305ddb6adb3cf03f636e1c0b80ca3a76b
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Mar 3 17:08:11 2017 +0100
x86/tboot: remove dead declarations
These aren't needed anymore as of c9a4a1c419 ("x86/layout: Correct
Xen's idea of its own memory layout").
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
commit 9152b5f8d917cccd811846d5dd48ade70fbae284
Author: Feng Wu <feng.wu@intel.com>
Date: Fri Mar 3 17:07:08 2017 +0100
VMX: properly handle pi when all the assigned devices are removed
This patch handles some corner cases when the last assigned device
is removed from the domain. In this case we should carefully handle
pi descriptor and the per-cpu blocking list, to make sure:
- all the PI descriptor are in the right state when next time a
devices is assigned to the domain again.
- No remaining vcpus of the domain in the per-cpu blocking list.
Here we call vmx_pi_unblock_vcpu() to remove the vCPU from the blocking list
if it is on the list. However, this could happen when vmx_vcpu_block() is
being called, hence we might incorrectly add the vCPU to the blocking list
while the last devcie is detached from the domain. Consider that the situation
can only occur when detaching the last device from the domain and it is not
a frequent operation, so we use domain_pause before that, which is considered
as an clean and maintainable solution for the situation.
Signed-off-by: Feng Wu <feng.wu@intel.com>
Signed-off-by: Chao Gao <chao.gao@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
commit 3176aa8a9515dcb7b60c8123f609dc3f84e57b57
Author: Wei Liu <wei.liu2@citrix.com>
Date: Wed Mar 1 15:35:24 2017 +0000
xen: include xen/types.h in domain.h
The public header expects a few types to be present.
This works in the code base only because types.h is included by some
other headers which happen to be placed before the inclusion of
domain.h.
Include types.h before xen.h in domain.h to fix it properly.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
commit 616de1d6bf2c56f7fc2dc77d8f572cfce8854df9
Author: Wei Liu <wei.liu2@citrix.com>
Date: Wed Mar 1 15:23:31 2017 +0000
xen: move round_pg{up,down} to pfn.h
They are going to be needed in multiple places. Instead of replicating
more, move them to pfn.h.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 92cf67888aeb8a7dd8c1d2e8e835b8b271c13ce1
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu Mar 2 11:41:17 2017 +0000
x86/emul: Hold x86_emulate() to strict X86EMUL_EXCEPTION requirements
All known paths raising faults behind the back of the emulator have been
fixed. Reinstate the original intended assertion concerning the behaviour of
X86EMUL_EXCEPTION and ctxt->event_pending.
As x86_emulate_wrapper() now covers both PV and HVM guests properly, there is
no need for the PV assertions following calls to x86_emulate().
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
commit 9c5a84fff576ad2e38d34d2b5d1a465e3129f298
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Thu Mar 2 12:41:38 2017 +0000
x86/hvm: Don't raise #GP behind the emulators back for CR writes
hvm_set_cr{0,4}() are reachable from the emulator, but use
hvm_inject_hw_exception() directly.
Alter the API to make the callers of hvm_set_cr{0,3,4}() responsible for
raising #GP, and apply this change to all existing callers.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
Issues identified which I am purposefully not fixing in this patch:
(I will try to get around to them, but probably not in the 4.9 timeframe, at
this point.)
* hvm_set_cr3() doesn't handle bad 32bit PAE PDPTRs properly, as it doesn't
actually have a path which raises #GP.
* There is a lot of redundancy in our HVM CR setting routines, but not enough
to trivially dedup at this point.
* Both nested VT-x and SVM are liable raise #GP with L1, rather than failing
the virtual vmentry/vmexit. This is not a change in behaviour, but is far
more obvious now.
* The hvm_do_resume() path for vm_event processing has the same bug as the
MSR side, where exceptions are raised after %rip has moved forwards. This
is also not a change in behaviour.
commit 3ae98aef839c1c420f04456a658f491d9580c4ba
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Fri Feb 3 13:55:26 2017 +0000
x86/kconfig: Introduce CONFIG_PV and CONFIG_HVM
Making PV and HVM guests individually compilable is useful as a reduction in
hypervisor size, and as an aid to enforcing clean API boundaries.
Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to do
until either can actually be disabled.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-unstable test] 106435: regressions - FAIL
2017-03-04 15:19 [xen-unstable test] 106435: regressions - FAIL osstest service owner
@ 2017-03-04 15:44 ` Andrew Cooper
2017-03-06 8:27 ` Paul Durrant
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cooper @ 2017-03-04 15:44 UTC (permalink / raw)
To: Paul Durrant; +Cc: xen-devel, osstest service owner, Jan Beulich
On 04/03/2017 15:19, osstest service owner wrote:
> flight 106435 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/106435/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 106412
> test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 106412
From
http://logs.test-lab.xenproject.org/osstest/logs/106435/test-amd64-amd64-xl-qemuu-win7-amd64/9.ts-windows-install.log
Mar 4 12:49:08.069641 (d3) Booting from DVD/CD...
Mar 4 12:49:08.069670 (d3) Booting from 0000:7c00
Mar 4 12:49:08.069697 (XEN) stdvga.c:178:d3v0 leaving stdvga mode
Mar 4 12:49:13.045676 (XEN) d3: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4 major: 6 minor: 1 sp: 0 build: 1db0
Mar 4 12:49:41.461683 (XEN) d3: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
Mar 4 12:49:41.461731 (XEN) d3v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn: 3fffe
Mar 4 12:49:41.469596 (XEN) domain_crash called from viridian.c:306
Mar 4 12:49:41.477595 (XEN) Domain 3 (vcpu#0) crashed on cpu#1:
Mar 4 12:49:41.477633 (XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not tainted ]----
Mar 4 12:49:41.485589 (XEN) CPU: 1
Mar 4 12:49:41.485620 (XEN) RIP: 0010:[<fffff80002653479>]
Mar 4 12:49:41.485650 (XEN) RFLAGS: 0000000000000286 CONTEXT: hvm guest (d3v0)
Mar 4 12:49:41.493591 (XEN) rax: 0000000000000000 rbx: fffff800027ede80 rcx: 0000000000000001
Mar 4 12:49:41.501560 (XEN) rdx: 0000000000000000 rsi: fffffa8001291040 rdi: fffff800027fbc40
Mar 4 12:49:41.509588 (XEN) rbp: 0000000000000080 rsp: fffff880009b0d80 r8: 0000000000000000
Mar 4 12:49:41.517584 (XEN) r9: fffff800027ede80 r10: fffffa8001291040 r11: fffff800027ede90
Mar 4 12:49:41.517624 (XEN) r12: fffff800008129c0 r13: fffff800028afbe0 r14: fffffa800122db30
Mar 4 12:49:41.525586 (XEN) r15: fffff80000b96080 cr0: 0000000080050031 cr4: 00000000000006b8
Mar 4 12:49:41.533582 (XEN) cr3: 0000000000187000 cr2: 0000000000000000
Mar 4 12:49:41.541578 (XEN) ds: 002b es: 002b fs: 0053 gs: 002b ss: 0018 cs: 0010
Looks like this intermittent bug is still biting. Should we kill
VIRIDIAN APIC_ASSIST until we have got to the bottom of it?
Alternatively, add some printk() to actually give us useful information
when it does go wrong.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-unstable test] 106435: regressions - FAIL
2017-03-04 15:44 ` Andrew Cooper
@ 2017-03-06 8:27 ` Paul Durrant
2017-03-06 13:52 ` Paul Durrant
0 siblings, 1 reply; 4+ messages in thread
From: Paul Durrant @ 2017-03-06 8:27 UTC (permalink / raw)
To: Andrew Cooper
Cc: xen-devel@lists.xensource.com, osstest service owner, Jan Beulich
> -----Original Message-----
> From: Andrew Cooper [mailto:amc96@hermes.cam.ac.uk] On Behalf Of
> Andrew Cooper
> Sent: 04 March 2017 15:45
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: osstest service owner <osstest-admin@xenproject.org>; xen-
> devel@lists.xensource.com; Jan Beulich <JBeulich@suse.com>
> Subject: Re: [Xen-devel] [xen-unstable test] 106435: regressions - FAIL
>
> On 04/03/2017 15:19, osstest service owner wrote:
> > flight 106435 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/106435/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs.
> 106412
> > test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 106412
>
> From
> http://logs.test-lab.xenproject.org/osstest/logs/106435/test-amd64-amd64-
> xl-qemuu-win7-amd64/9.ts-windows-install.log
>
> Mar 4 12:49:08.069641 (d3) Booting from DVD/CD...
> Mar 4 12:49:08.069670 (d3) Booting from 0000:7c00
> Mar 4 12:49:08.069697 (XEN) stdvga.c:178:d3v0 leaving stdvga mode
> Mar 4 12:49:13.045676 (XEN) d3: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4
> major: 6 minor: 1 sp: 0 build: 1db0
> Mar 4 12:49:41.461683 (XEN) d3: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
> Mar 4 12:49:41.461731 (XEN) d3v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn:
> 3fffe
> Mar 4 12:49:41.469596 (XEN) domain_crash called from viridian.c:306
> Mar 4 12:49:41.477595 (XEN) Domain 3 (vcpu#0) crashed on cpu#1:
> Mar 4 12:49:41.477633 (XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not
> tainted ]----
> Mar 4 12:49:41.485589 (XEN) CPU: 1
> Mar 4 12:49:41.485620 (XEN) RIP: 0010:[<fffff80002653479>]
> Mar 4 12:49:41.485650 (XEN) RFLAGS: 0000000000000286 CONTEXT: hvm
> guest (d3v0)
> Mar 4 12:49:41.493591 (XEN) rax: 0000000000000000 rbx: fffff800027ede80
> rcx: 0000000000000001
> Mar 4 12:49:41.501560 (XEN) rdx: 0000000000000000 rsi: fffffa8001291040
> rdi: fffff800027fbc40
> Mar 4 12:49:41.509588 (XEN) rbp: 0000000000000080 rsp: fffff880009b0d80
> r8: 0000000000000000
> Mar 4 12:49:41.517584 (XEN) r9: fffff800027ede80 r10: fffffa8001291040
> r11: fffff800027ede90
> Mar 4 12:49:41.517624 (XEN) r12: fffff800008129c0 r13: fffff800028afbe0
> r14: fffffa800122db30
> Mar 4 12:49:41.525586 (XEN) r15: fffff80000b96080 cr0: 0000000080050031
> cr4: 00000000000006b8
> Mar 4 12:49:41.533582 (XEN) cr3: 0000000000187000 cr2: 0000000000000000
> Mar 4 12:49:41.541578 (XEN) ds: 002b es: 002b fs: 0053 gs: 002b ss: 0018
> cs: 0010
>
>
> Looks like this intermittent bug is still biting. Should we kill
> VIRIDIAN APIC_ASSIST until we have got to the bottom of it?
> Alternatively, add some printk() to actually give us useful information
> when it does go wrong.
I actually think this may be a bug in Windows 7. I normally run with this enlightenment on and have seen this very occasionally and only with Windows 7.
I think it would probably be useful to stash info about the last interrupt injected into the guest and then reduce the domain_crash() to a gprintk() dumping that info plus info about the interrupt that's about to be injected. I'll post a patch.
Paul
>
> ~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-unstable test] 106435: regressions - FAIL
2017-03-06 8:27 ` Paul Durrant
@ 2017-03-06 13:52 ` Paul Durrant
0 siblings, 0 replies; 4+ messages in thread
From: Paul Durrant @ 2017-03-06 13:52 UTC (permalink / raw)
To: Paul Durrant, Andrew Cooper
Cc: xen-devel@lists.xensource.com, osstest service owner, Jan Beulich
> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 06 March 2017 08:28
> To: Andrew Cooper <Andrew.Cooper3@citrix.com>
> Cc: xen-devel@lists.xensource.com; osstest service owner <osstest-
> admin@xenproject.org>; Jan Beulich <JBeulich@suse.com>
> Subject: Re: [Xen-devel] [xen-unstable test] 106435: regressions - FAIL
>
> > -----Original Message-----
> > From: Andrew Cooper [mailto:amc96@hermes.cam.ac.uk] On Behalf Of
> > Andrew Cooper
> > Sent: 04 March 2017 15:45
> > To: Paul Durrant <Paul.Durrant@citrix.com>
> > Cc: osstest service owner <osstest-admin@xenproject.org>; xen-
> > devel@lists.xensource.com; Jan Beulich <JBeulich@suse.com>
> > Subject: Re: [Xen-devel] [xen-unstable test] 106435: regressions - FAIL
> >
> > On 04/03/2017 15:19, osstest service owner wrote:
> > > flight 106435 xen-unstable real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/106435/
> > >
> > > Regressions :-(
> > >
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > > test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR.
> vs.
> > 106412
> > > test-armhf-armhf-libvirt-raw 9 debian-di-install fail REGR. vs. 106412
> >
> > From
> > http://logs.test-lab.xenproject.org/osstest/logs/106435/test-amd64-
> amd64-
> > xl-qemuu-win7-amd64/9.ts-windows-install.log
> >
> > Mar 4 12:49:08.069641 (d3) Booting from DVD/CD...
> > Mar 4 12:49:08.069670 (d3) Booting from 0000:7c00
> > Mar 4 12:49:08.069697 (XEN) stdvga.c:178:d3v0 leaving stdvga mode
> > Mar 4 12:49:13.045676 (XEN) d3: VIRIDIAN GUEST_OS_ID: vendor: 1 os: 4
> > major: 6 minor: 1 sp: 0 build: 1db0
> > Mar 4 12:49:41.461683 (XEN) d3: VIRIDIAN HYPERCALL: enabled: 1 pfn: 3ffff
> > Mar 4 12:49:41.461731 (XEN) d3v0: VIRIDIAN APIC_ASSIST: enabled: 1 pfn:
> > 3fffe
> > Mar 4 12:49:41.469596 (XEN) domain_crash called from viridian.c:306
> > Mar 4 12:49:41.477595 (XEN) Domain 3 (vcpu#0) crashed on cpu#1:
> > Mar 4 12:49:41.477633 (XEN) ----[ Xen-4.9-unstable x86_64 debug=y Not
> > tainted ]----
> > Mar 4 12:49:41.485589 (XEN) CPU: 1
> > Mar 4 12:49:41.485620 (XEN) RIP: 0010:[<fffff80002653479>]
> > Mar 4 12:49:41.485650 (XEN) RFLAGS: 0000000000000286 CONTEXT: hvm
> > guest (d3v0)
> > Mar 4 12:49:41.493591 (XEN) rax: 0000000000000000 rbx: fffff800027ede80
> > rcx: 0000000000000001
> > Mar 4 12:49:41.501560 (XEN) rdx: 0000000000000000 rsi: fffffa8001291040
> > rdi: fffff800027fbc40
> > Mar 4 12:49:41.509588 (XEN) rbp: 0000000000000080 rsp: fffff880009b0d80
> > r8: 0000000000000000
> > Mar 4 12:49:41.517584 (XEN) r9: fffff800027ede80 r10: fffffa8001291040
> > r11: fffff800027ede90
> > Mar 4 12:49:41.517624 (XEN) r12: fffff800008129c0 r13: fffff800028afbe0
> > r14: fffffa800122db30
> > Mar 4 12:49:41.525586 (XEN) r15: fffff80000b96080 cr0: 0000000080050031
> > cr4: 00000000000006b8
> > Mar 4 12:49:41.533582 (XEN) cr3: 0000000000187000 cr2:
> 0000000000000000
> > Mar 4 12:49:41.541578 (XEN) ds: 002b es: 002b fs: 0053 gs: 002b ss: 0018
> > cs: 0010
> >
> >
> > Looks like this intermittent bug is still biting. Should we kill
> > VIRIDIAN APIC_ASSIST until we have got to the bottom of it?
> > Alternatively, add some printk() to actually give us useful information
> > when it does go wrong.
>
> I actually think this may be a bug in Windows 7. I normally run with this
> enlightenment on and have seen this very occasionally and only with
> Windows 7.
>
> I think it would probably be useful to stash info about the last interrupt
> injected into the guest and then reduce the domain_crash() to a gprintk()
> dumping that info plus info about the interrupt that's about to be injected. I'll
> post a patch.
Actually I think I may have figured this out...
If a buggy version of Windows enables APIC assist (by setting up the shared page) but then performs an EOI without checking/clearing the bit in the page this will result in a domain_crash(). The reasoning is as follows:
- Performing the EOI will clear the vector from the ISR but will not clear the pending assist information.
- The next call to vlapic_has_pending_irq() will also not clear the pending assist information (because the assist bit is still set), but it will return a valid vector.
- The subsequent call to vlapic_ack_pending_irq() will then call viridian_start_apic_assist() which will invoke domain_crash() because it detects that there is a pending assist.
The OS is at fault because, by setting up the APIC assist page, it is guaranteeing to the hypervisor this it will check/clear the bit. But it's easy enough to work around the bug by simply aborting any pending APIC assist in the EOI handler. I'll test a patch that does this and post later.
Paul
>
> Paul
>
> >
> > ~Andrew
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-03-06 13:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-04 15:19 [xen-unstable test] 106435: regressions - FAIL osstest service owner
2017-03-04 15:44 ` Andrew Cooper
2017-03-06 8:27 ` Paul Durrant
2017-03-06 13:52 ` Paul Durrant
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.