* [xen-unstable test] 33690: regressions - FAIL
@ 2015-01-24 12:54 xen.org
2015-01-26 11:04 ` Jan Beulich
0 siblings, 1 reply; 7+ messages in thread
From: xen.org @ 2015-01-24 12:54 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
[-- Attachment #1: Type: text/plain, Size: 7748 bytes --]
flight 33690 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 33637
test-amd64-i386-freebsd10-i386 8 guest-start fail REGR. vs. 33637
test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 33637
test-amd64-i386-pair 7 xen-boot/src_host fail REGR. vs. 33637
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 33637
test-amd64-i386-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 33637
test-amd64-i386-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 33637
test-amd64-amd64-xl-winxpsp3 7 windows-install fail REGR. vs. 33637
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 33637
test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637
test-amd64-i386-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637
test-amd64-i386-xl-win7-amd64 7 windows-install fail REGR. vs. 33637
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf-pin 5 xen-boot fail REGR. vs. 33637
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start fail never pass
test-amd64-amd64-xl-pvh-intel 9 guest-start fail never pass
test-amd64-amd64-xl-pvh-amd 9 guest-start fail never pass
test-armhf-armhf-libvirt 9 guest-start fail never pass
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-armhf-armhf-xl 10 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass
version targeted for testing:
xen 49de0b57b853064d6b3ad1646fafe08b8dcaac98
baseline version:
xen 7106c691a6332cffab4037186d1caa3012ae051e
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Boris Ostrovsky <boris.ostrovsky@oracle.com>
David Vrabel <david.vrabel@citrix.com>
Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Kevin Tian <kevin.tian@intel.com>
Roger Pau Monné <roger.pau@citrix.com>
Tim Deegan <tim@xen.org>
Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumpuserxen pass
build-i386-rumpuserxen pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-rhel6hvm-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 fail
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-rumpuserxen-amd64 fail
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-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-i386-freebsd10-i386 fail
test-amd64-i386-rumpuserxen-i386 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair fail
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-xl-sedf pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-i386-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xl-qemuu-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
test-amd64-i386-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 557 lines long.)
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [xen-unstable test] 33690: regressions - FAIL
2015-01-24 12:54 [xen-unstable test] 33690: regressions - FAIL xen.org
@ 2015-01-26 11:04 ` Jan Beulich
2015-01-26 11:38 ` Jan Beulich
0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2015-01-26 11:04 UTC (permalink / raw)
To: Boris Ostrovsky; +Cc: xen-devel
>>> On 24.01.15 at 13:54, <Ian.Jackson@eu.citrix.com> wrote:
> flight 33690 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33690/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-rumpuserxen-amd64 11 rumpuserxen-demo-xenstorels/xenstorels fail REGR. vs. 33637
> test-amd64-i386-freebsd10-i386 8 guest-start fail REGR. vs. 33637
> test-amd64-amd64-xl-qemut-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 33637
> test-amd64-i386-pair 7 xen-boot/src_host fail REGR. vs. 33637
> test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 33637
> test-amd64-i386-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 33637
> test-amd64-i386-xl-qemuu-winxpsp3 7 windows-install fail REGR. vs. 33637
> test-amd64-amd64-xl-winxpsp3 7 windows-install fail REGR. vs. 33637
> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 7 windows-install fail REGR. vs. 33637
> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637
Jan 24 00:35:16.262627 (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Not tainted ]----
Jan 24 00:35:16.478599 (XEN) CPU: 1
Jan 24 00:35:16.478624 (XEN) RIP: e008:[<0000000000000000>] 0000000000000000
Jan 24 00:35:16.486596 (XEN) RFLAGS: 0000000000010082 CONTEXT: hypervisor
...
Jan 24 00:35:16.678620 (XEN) Xen call trace:
Jan 24 00:35:16.678650 (XEN) [<ffff82d0801d36d0>] vpmu_do_interrupt+0x2f/0x8a
Jan 24 00:35:16.686605 (XEN) [<ffff82d08015e242>] pmu_apic_interrupt+0x33/0x35
Jan 24 00:35:16.698582 (XEN) [<ffff82d080171bf0>] do_IRQ+0x9c/0x624
Jan 24 00:35:16.698615 (XEN) [<ffff82d080234062>] common_interrupt+0x62/0x70
Jan 24 00:35:16.698653 (XEN) [<ffff82d08012c6fe>] _spin_unlock_irq+0x30/0x31
Jan 24 00:35:16.706604 (XEN) [<ffff82d08012bcf1>] __do_softirq+0x81/0x8c
Jan 24 00:35:16.706638 (XEN) [<ffff82d08012bd49>] do_softirq+0x13/0x15
Jan 24 00:35:16.718591 (XEN) [<ffff82d0801ec4da>] vmx_asm_do_vmentry+0x2a/0x50
Others look similar. Please advise which of the 8 patches that went
in on Friday from the beginning of your vPMU series need to be
reverted. Please also explain how, with vPMU support being off by
default, execution reaches vPMU code in the first place.
Jan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [xen-unstable test] 33690: regressions - FAIL
2015-01-26 11:04 ` Jan Beulich
@ 2015-01-26 11:38 ` Jan Beulich
2015-01-26 14:49 ` Andrew Cooper
0 siblings, 1 reply; 7+ messages in thread
From: Jan Beulich @ 2015-01-26 11:38 UTC (permalink / raw)
To: Boris Ostrovsky; +Cc: xen-devel
>>> On 26.01.15 at 12:04, <JBeulich@suse.com> wrote:
>>>> On 24.01.15 at 13:54, <Ian.Jackson@eu.citrix.com> wrote:
>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637
>
> Jan 24 00:35:16.262627 (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Not tainted ]----
> Jan 24 00:35:16.478599 (XEN) CPU: 1
> Jan 24 00:35:16.478624 (XEN) RIP: e008:[<0000000000000000>] 0000000000000000
> Jan 24 00:35:16.486596 (XEN) RFLAGS: 0000000000010082 CONTEXT: hypervisor
> ...
> Jan 24 00:35:16.678620 (XEN) Xen call trace:
> Jan 24 00:35:16.678650 (XEN) [<ffff82d0801d36d0>] vpmu_do_interrupt+0x2f/0x8a
> Jan 24 00:35:16.686605 (XEN) [<ffff82d08015e242>] pmu_apic_interrupt+0x33/0x35
> Jan 24 00:35:16.698582 (XEN) [<ffff82d080171bf0>] do_IRQ+0x9c/0x624
> Jan 24 00:35:16.698615 (XEN) [<ffff82d080234062>] common_interrupt+0x62/0x70
> Jan 24 00:35:16.698653 (XEN) [<ffff82d08012c6fe>] _spin_unlock_irq+0x30/0x31
> Jan 24 00:35:16.706604 (XEN) [<ffff82d08012bcf1>] __do_softirq+0x81/0x8c
> Jan 24 00:35:16.706638 (XEN) [<ffff82d08012bd49>] do_softirq+0x13/0x15
> Jan 24 00:35:16.718591 (XEN) [<ffff82d0801ec4da>] vmx_asm_do_vmentry+0x2a/0x50
I think I see what the problem here is: Commit 8097616fbd
("x86/VPMU: handle APIC_LVTPC accesses") gives the guest
control over LVTPC.mask regardless of whether the vPMU was
actually initialized for it. Supposedly in the case above the
guest is being run with core2_no_vpmu_ops, which in
particular has .do_interrupt == NULL. It's not immediately
clear whether vpmu_lvtpc_update() should do the check or its
(sole) caller. In any event I'm going to revert that commit as
the primary suspect for causing the regression.
Jan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [xen-unstable test] 33690: regressions - FAIL
2015-01-26 11:38 ` Jan Beulich
@ 2015-01-26 14:49 ` Andrew Cooper
2015-01-26 14:51 ` Boris Ostrovsky
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Cooper @ 2015-01-26 14:49 UTC (permalink / raw)
To: Jan Beulich, Boris Ostrovsky; +Cc: xen-devel
On 26/01/15 11:38, Jan Beulich wrote:
>>>> On 26.01.15 at 12:04, <JBeulich@suse.com> wrote:
>>>>> On 24.01.15 at 13:54, <Ian.Jackson@eu.citrix.com> wrote:
>>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637
>> Jan 24 00:35:16.262627 (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Not tainted ]----
>> Jan 24 00:35:16.478599 (XEN) CPU: 1
>> Jan 24 00:35:16.478624 (XEN) RIP: e008:[<0000000000000000>] 0000000000000000
>> Jan 24 00:35:16.486596 (XEN) RFLAGS: 0000000000010082 CONTEXT: hypervisor
>> ...
>> Jan 24 00:35:16.678620 (XEN) Xen call trace:
>> Jan 24 00:35:16.678650 (XEN) [<ffff82d0801d36d0>] vpmu_do_interrupt+0x2f/0x8a
>> Jan 24 00:35:16.686605 (XEN) [<ffff82d08015e242>] pmu_apic_interrupt+0x33/0x35
>> Jan 24 00:35:16.698582 (XEN) [<ffff82d080171bf0>] do_IRQ+0x9c/0x624
>> Jan 24 00:35:16.698615 (XEN) [<ffff82d080234062>] common_interrupt+0x62/0x70
>> Jan 24 00:35:16.698653 (XEN) [<ffff82d08012c6fe>] _spin_unlock_irq+0x30/0x31
>> Jan 24 00:35:16.706604 (XEN) [<ffff82d08012bcf1>] __do_softirq+0x81/0x8c
>> Jan 24 00:35:16.706638 (XEN) [<ffff82d08012bd49>] do_softirq+0x13/0x15
>> Jan 24 00:35:16.718591 (XEN) [<ffff82d0801ec4da>] vmx_asm_do_vmentry+0x2a/0x50
> I think I see what the problem here is: Commit 8097616fbd
> ("x86/VPMU: handle APIC_LVTPC accesses") gives the guest
> control over LVTPC.mask regardless of whether the vPMU was
> actually initialized for it. Supposedly in the case above the
> guest is being run with core2_no_vpmu_ops, which in
> particular has .do_interrupt == NULL. It's not immediately
> clear whether vpmu_lvtpc_update() should do the check or its
> (sole) caller. In any event I'm going to revert that commit as
> the primary suspect for causing the regression.
I have just fallen over this as well. I second a revert in the absence
of a clear way to fix the patch.
~Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [xen-unstable test] 33690: regressions - FAIL
2015-01-26 14:49 ` Andrew Cooper
@ 2015-01-26 14:51 ` Boris Ostrovsky
2015-01-26 14:56 ` Andrew Cooper
0 siblings, 1 reply; 7+ messages in thread
From: Boris Ostrovsky @ 2015-01-26 14:51 UTC (permalink / raw)
To: Andrew Cooper, Jan Beulich; +Cc: xen-devel
On 01/26/2015 09:49 AM, Andrew Cooper wrote:
> On 26/01/15 11:38, Jan Beulich wrote:
>>>>> On 26.01.15 at 12:04, <JBeulich@suse.com> wrote:
>>>>>> On 24.01.15 at 13:54, <Ian.Jackson@eu.citrix.com> wrote:
>>>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail REGR. vs. 33637
>>> Jan 24 00:35:16.262627 (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Not tainted ]----
>>> Jan 24 00:35:16.478599 (XEN) CPU: 1
>>> Jan 24 00:35:16.478624 (XEN) RIP: e008:[<0000000000000000>] 0000000000000000
>>> Jan 24 00:35:16.486596 (XEN) RFLAGS: 0000000000010082 CONTEXT: hypervisor
>>> ...
>>> Jan 24 00:35:16.678620 (XEN) Xen call trace:
>>> Jan 24 00:35:16.678650 (XEN) [<ffff82d0801d36d0>] vpmu_do_interrupt+0x2f/0x8a
>>> Jan 24 00:35:16.686605 (XEN) [<ffff82d08015e242>] pmu_apic_interrupt+0x33/0x35
>>> Jan 24 00:35:16.698582 (XEN) [<ffff82d080171bf0>] do_IRQ+0x9c/0x624
>>> Jan 24 00:35:16.698615 (XEN) [<ffff82d080234062>] common_interrupt+0x62/0x70
>>> Jan 24 00:35:16.698653 (XEN) [<ffff82d08012c6fe>] _spin_unlock_irq+0x30/0x31
>>> Jan 24 00:35:16.706604 (XEN) [<ffff82d08012bcf1>] __do_softirq+0x81/0x8c
>>> Jan 24 00:35:16.706638 (XEN) [<ffff82d08012bd49>] do_softirq+0x13/0x15
>>> Jan 24 00:35:16.718591 (XEN) [<ffff82d0801ec4da>] vmx_asm_do_vmentry+0x2a/0x50
>> I think I see what the problem here is: Commit 8097616fbd
>> ("x86/VPMU: handle APIC_LVTPC accesses") gives the guest
>> control over LVTPC.mask regardless of whether the vPMU was
>> actually initialized for it. Supposedly in the case above the
>> guest is being run with core2_no_vpmu_ops, which in
>> particular has .do_interrupt == NULL. It's not immediately
>> clear whether vpmu_lvtpc_update() should do the check or its
>> (sole) caller. In any event I'm going to revert that commit as
>> the primary suspect for causing the regression.
> I have just fallen over this as well. I second a revert in the absence
> of a clear way to fix the patch.
I can't reproduce this -- neither at this patch level nor at full series.
Yes, we can test for do_interrupt presence in vpmu_lvtpc_update() (or in
vpmu_interrupt() itself) but since we cannot arm the counters (there is
no do_wrmsr op) I am not sure I understand what can trigger this interrupt.
-boris
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [xen-unstable test] 33690: regressions - FAIL
2015-01-26 14:51 ` Boris Ostrovsky
@ 2015-01-26 14:56 ` Andrew Cooper
2015-01-26 15:08 ` Boris Ostrovsky
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Cooper @ 2015-01-26 14:56 UTC (permalink / raw)
To: Boris Ostrovsky, Jan Beulich; +Cc: xen-devel
On 26/01/15 14:51, Boris Ostrovsky wrote:
> On 01/26/2015 09:49 AM, Andrew Cooper wrote:
>> On 26/01/15 11:38, Jan Beulich wrote:
>>>>>> On 26.01.15 at 12:04, <JBeulich@suse.com> wrote:
>>>>>>> On 24.01.15 at 13:54, <Ian.Jackson@eu.citrix.com> wrote:
>>>>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail
>>>>> REGR. vs. 33637
>>>> Jan 24 00:35:16.262627 (XEN) ----[ Xen-4.6-unstable x86_64
>>>> debug=y Not tainted ]----
>>>> Jan 24 00:35:16.478599 (XEN) CPU: 1
>>>> Jan 24 00:35:16.478624 (XEN) RIP: e008:[<0000000000000000>]
>>>> 0000000000000000
>>>> Jan 24 00:35:16.486596 (XEN) RFLAGS: 0000000000010082 CONTEXT:
>>>> hypervisor
>>>> ...
>>>> Jan 24 00:35:16.678620 (XEN) Xen call trace:
>>>> Jan 24 00:35:16.678650 (XEN) [<ffff82d0801d36d0>]
>>>> vpmu_do_interrupt+0x2f/0x8a
>>>> Jan 24 00:35:16.686605 (XEN) [<ffff82d08015e242>]
>>>> pmu_apic_interrupt+0x33/0x35
>>>> Jan 24 00:35:16.698582 (XEN) [<ffff82d080171bf0>] do_IRQ+0x9c/0x624
>>>> Jan 24 00:35:16.698615 (XEN) [<ffff82d080234062>]
>>>> common_interrupt+0x62/0x70
>>>> Jan 24 00:35:16.698653 (XEN) [<ffff82d08012c6fe>]
>>>> _spin_unlock_irq+0x30/0x31
>>>> Jan 24 00:35:16.706604 (XEN) [<ffff82d08012bcf1>]
>>>> __do_softirq+0x81/0x8c
>>>> Jan 24 00:35:16.706638 (XEN) [<ffff82d08012bd49>]
>>>> do_softirq+0x13/0x15
>>>> Jan 24 00:35:16.718591 (XEN) [<ffff82d0801ec4da>]
>>>> vmx_asm_do_vmentry+0x2a/0x50
>>> I think I see what the problem here is: Commit 8097616fbd
>>> ("x86/VPMU: handle APIC_LVTPC accesses") gives the guest
>>> control over LVTPC.mask regardless of whether the vPMU was
>>> actually initialized for it. Supposedly in the case above the
>>> guest is being run with core2_no_vpmu_ops, which in
>>> particular has .do_interrupt == NULL. It's not immediately
>>> clear whether vpmu_lvtpc_update() should do the check or its
>>> (sole) caller. In any event I'm going to revert that commit as
>>> the primary suspect for causing the regression.
>> I have just fallen over this as well. I second a revert in the absence
>> of a clear way to fix the patch.
>
> I can't reproduce this -- neither at this patch level nor at full series.
>
> Yes, we can test for do_interrupt presence in vpmu_lvtpc_update() (or
> in vpmu_interrupt() itself) but since we cannot arm the counters
> (there is no do_wrmsr op) I am not sure I understand what can trigger
> this interrupt.
>
> -boris
>
>
As Jan explained, The patch in question allows guests (windows in both
problematic cases) to arm LVTPC, with a vpmu instance with a NULL
pointer for do_interrupt.
When a pmu apic interrupt arrives, the interrupt handler dies from a
NULL function pointer dereference.
~Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [xen-unstable test] 33690: regressions - FAIL
2015-01-26 14:56 ` Andrew Cooper
@ 2015-01-26 15:08 ` Boris Ostrovsky
0 siblings, 0 replies; 7+ messages in thread
From: Boris Ostrovsky @ 2015-01-26 15:08 UTC (permalink / raw)
To: Andrew Cooper, Jan Beulich; +Cc: xen-devel
On 01/26/2015 09:56 AM, Andrew Cooper wrote:
> On 26/01/15 14:51, Boris Ostrovsky wrote:
>> On 01/26/2015 09:49 AM, Andrew Cooper wrote:
>>> On 26/01/15 11:38, Jan Beulich wrote:
>>>>>>> On 26.01.15 at 12:04, <JBeulich@suse.com> wrote:
>>>>>>>> On 24.01.15 at 13:54, <Ian.Jackson@eu.citrix.com> wrote:
>>>>>> test-amd64-amd64-xl-qemut-win7-amd64 7 windows-install fail
>>>>>> REGR. vs. 33637
>>>>> Jan 24 00:35:16.262627 (XEN) ----[ Xen-4.6-unstable x86_64
>>>>> debug=y Not tainted ]----
>>>>> Jan 24 00:35:16.478599 (XEN) CPU: 1
>>>>> Jan 24 00:35:16.478624 (XEN) RIP: e008:[<0000000000000000>]
>>>>> 0000000000000000
>>>>> Jan 24 00:35:16.486596 (XEN) RFLAGS: 0000000000010082 CONTEXT:
>>>>> hypervisor
>>>>> ...
>>>>> Jan 24 00:35:16.678620 (XEN) Xen call trace:
>>>>> Jan 24 00:35:16.678650 (XEN) [<ffff82d0801d36d0>]
>>>>> vpmu_do_interrupt+0x2f/0x8a
>>>>> Jan 24 00:35:16.686605 (XEN) [<ffff82d08015e242>]
>>>>> pmu_apic_interrupt+0x33/0x35
>>>>> Jan 24 00:35:16.698582 (XEN) [<ffff82d080171bf0>] do_IRQ+0x9c/0x624
>>>>> Jan 24 00:35:16.698615 (XEN) [<ffff82d080234062>]
>>>>> common_interrupt+0x62/0x70
>>>>> Jan 24 00:35:16.698653 (XEN) [<ffff82d08012c6fe>]
>>>>> _spin_unlock_irq+0x30/0x31
>>>>> Jan 24 00:35:16.706604 (XEN) [<ffff82d08012bcf1>]
>>>>> __do_softirq+0x81/0x8c
>>>>> Jan 24 00:35:16.706638 (XEN) [<ffff82d08012bd49>]
>>>>> do_softirq+0x13/0x15
>>>>> Jan 24 00:35:16.718591 (XEN) [<ffff82d0801ec4da>]
>>>>> vmx_asm_do_vmentry+0x2a/0x50
>>>> I think I see what the problem here is: Commit 8097616fbd
>>>> ("x86/VPMU: handle APIC_LVTPC accesses") gives the guest
>>>> control over LVTPC.mask regardless of whether the vPMU was
>>>> actually initialized for it. Supposedly in the case above the
>>>> guest is being run with core2_no_vpmu_ops, which in
>>>> particular has .do_interrupt == NULL. It's not immediately
>>>> clear whether vpmu_lvtpc_update() should do the check or its
>>>> (sole) caller. In any event I'm going to revert that commit as
>>>> the primary suspect for causing the regression.
>>> I have just fallen over this as well. I second a revert in the absence
>>> of a clear way to fix the patch.
>> I can't reproduce this -- neither at this patch level nor at full series.
>>
>> Yes, we can test for do_interrupt presence in vpmu_lvtpc_update() (or
>> in vpmu_interrupt() itself) but since we cannot arm the counters
>> (there is no do_wrmsr op) I am not sure I understand what can trigger
>> this interrupt.
>>
>> -boris
>>
>>
> As Jan explained, The patch in question allows guests (windows in both
> problematic cases) to arm LVTPC, with a vpmu instance with a NULL
> pointer for do_interrupt.
Right, I understand that. But you'd need to arm the counters (not just
APIC) for the interrupt to happen, wouldn't you? And I don't see how
that can happen.
This issue also appears to happen on debian, so it's not Windows only.
In any case, you should indeed revert this until I resend a safer patch.
Before I do that I'd like to be able to reproduce this though.
-boris
>
> When a pmu apic interrupt arrives, the interrupt handler dies from a
> NULL function pointer dereference.
>
> ~Andrew
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-01-26 15:08 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-24 12:54 [xen-unstable test] 33690: regressions - FAIL xen.org
2015-01-26 11:04 ` Jan Beulich
2015-01-26 11:38 ` Jan Beulich
2015-01-26 14:49 ` Andrew Cooper
2015-01-26 14:51 ` Boris Ostrovsky
2015-01-26 14:56 ` Andrew Cooper
2015-01-26 15:08 ` Boris Ostrovsky
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.