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

[Julien Grall <julien.grall@xxxxxxxxx>]

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?

I have CCed Andre who might be able to help while I am away.

Cheers,

 -George

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

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