Hi, Sorry for the late reply and formatting, writing from my phone.
On Wed, 30 Aug 2017, 15:17 George Dunlap <george.dun...@citrix.com> 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@lists.xen.org > https://lists.xen.org/xen-devel >
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
