[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable-smoke test] 112957: regressions - trouble: broken/fail/pass



On 09/02/2017 04:39 PM, Julien Grall wrote:
> Hi,
> 
> Sorry for the late reply and formatting, writing from my phone.
> 
> On Wed, 30 Aug 2017, 15:17 George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
> 
>> On 08/30/2017 02:54 PM, Andrew Cooper wrote:
>>> On 30/08/17 14:49, osstest service owner wrote:
>>>> flight 112957 xen-unstable-smoke real [real]
>>>> http://logs.test-lab.xenproject.org/osstest/logs/112957/
>>>>
>>>> Regressions :-(
>>>>
>>>> Tests which did not succeed and are blocking,
>>>> including tests which could not be run:
>>>>  test-armhf-armhf-xl          12 guest-start              fail REGR.
>> vs. 112956
>>>
>>> (XEN) Assertion 'cpu == smp_processor_id()' failed at softirq.c:35
>>> (XEN) ----[ Xen-4.10-unstable  arm32  debug=y   Not tainted ]----
>>> (XEN) CPU:    1
>>> (XEN) PC:     0023b710 softirq.c#__do_softirq+0x3c/0x134
>>> (XEN) CPSR:   8000005a MODE:Hypervisor
>>> (XEN)      R0: 4003d000 R1: 00000001 R2: 3fcffd00 R3: 00000001
>>> (XEN)      R4: 002e5f74 R5: 00000000 R6: 0031d694 R7: 0031a224
>>> (XEN)      R8: 002e1f80 R9: 0029b880 R10:00000001 R11:40037f3c
>> R12:00000000
>>> (XEN) HYP: SP: 40037f04 LR: 0025826c
>>> (XEN)
>>> (XEN)   VTCR_EL2: 80003558
>>> (XEN)  VTTBR_EL2: 00010000bff1e000
>>> (XEN)
>>> (XEN)  SCTLR_EL2: 30cd187f
>>> (XEN)    HCR_EL2: 000000000038663f
>>> (XEN)  TTBR0_EL2: 00000000ba016000
>>> (XEN)
>>> (XEN)    ESR_EL2: 00000000
>>> (XEN)  HPFAR_EL2: 0000000000104810
>>> (XEN)      HDFAR: df000f00
>>> (XEN)      HIFAR: 00000000
>>> (XEN)
>>> (XEN) Xen stack trace from sp=40037f04:
>>> (XEN)    00000000 00000004 002e1f80 00000000 00000000 002e1f80 0031d694
>> 002e1f80
>>> (XEN)    c1203098 00000001 00000000 00000000 c11151a8 40037f44 0023b87c
>> 40037f54
>>> (XEN)    0026b320 c1200000 c1203034 40037f58 0026ef40 00000001 00000000
>> 00000001
>>> (XEN)    c031c520 c1200000 c1203034 c1203098 00000001 00000000 00000000
>> c11151a8
>>> (XEN)    c12030a0 192b8000 ffffffff 7f5706d3 c031c528 60000093 07e00000
>> bebcd108
>>> (XEN)    c1318ac0 c030d0a0 c1201fa0 c030928c c1318acc c030d420 c1318ad8
>> c030d4e0
>>> (XEN)    00000000 00000000 00000000 00000000 00000000 c1318ae4 c1318ae4
>> 60000013
>>> (XEN)    60010193 20000093 60000193 00000000 00000000 00000000 00000000
>>> (XEN) Xen call trace:
>>> (XEN)    [<0023b710>] softirq.c#__do_softirq+0x3c/0x134 (PC)
>>> (XEN)    [<0025826c>] domain.c#schedule_tail+0x2f4/0x308 (LR)
>>> (XEN)    [<0023b87c>] do_softirq+0x18/0x28
>>> (XEN)    [<0026b320>] leave_hypervisor_tail+0x84/0xb8
>>> (XEN)    [<0026ef40>] entry.o#return_to_guest+0xc/0xb8
>>> (XEN)
>>> (XEN)
>>> (XEN) ****************************************
>>> (XEN) Panic on CPU 1:
>>> (XEN) Assertion 'cpu == smp_processor_id()' failed at softirq.c:35
>>> (XEN) ****************************************
>>> (XEN)
>>> (XEN) Manual reset required ('noreboot' specified)
>>>
>>> At a guess, I'd say the reasoning behind
>>>
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=57450cfe48b56db90166c52d45a411a9279a12e1
>>> is false.
>>
>> Wow -- I actually rather doubt that the reasoning is wrong; I can't see
>> anywhere in the context switch path that could possibly move the
>> hypervisor stack to another processor.  I'd be more inclined to suspect
>> that smp_processor_id() returns the wrong value under certain conditions
>> -- e.g., between a schedule() softirq and the next VMENTER (whatever
>> it's called on ARM).
>>
>> Stefano, any ideas?
>>
> 
> If I am not mistaken the hypervisor stack is per-vCPU. So when you move the
> vCPU to another pCPU, the stack will be moved.
> This means the smp_processor_id() will return a different value. Isn't it
> the same on x86?

No, the hypervisor stack on x86 has always been per-pcpu.  Apparently
the powerpc port was per-vcpu, which is why the smp_processor_id() was
there.  I (and apparently Dario) assumed the ARM implementation was the
same as x86, which is why I checked in this change.

I guess we'd better leave the patch reverted for now.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.