On Tue, 29 May 2018 11:59:44 +1000 Paul Mackerras <paulus@xxxxxxxxxx> wrote: > On Fri, May 25, 2018 at 12:48:31PM +0200, Greg Kurz wrote: > > > I could reproduced the problem if I boot the L2 guest with an upstream > > kernel (commit d7b66b4ab034). I've tried to dump the log_buf but things > > didn't go well: > > > > $ grep 'd log_buf' System.map > > c000000001304f08 d log_buf_len > > c000000001304f10 d log_buf > > > > (qemu) x 0xc000000001304f08 > > c000000001304f08: Cannot access memory > > I would use "xp 0x1304f08". > Dumb me, virtual addresses don't work this early... :-\ And the panic message confirms that we're hitting the BUG() in pseries_lpar_register_process_table(). fFailed to register process table (rc=-4) ------------[ cut here ]------------ Fkernel BUG at arch/powerpc/platforms/pseries/lpar.c:750! Oops: Exception in kernel mode, sig: 5 [#1] LE SMP NR_CPUS=1024 NUMA Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.17.0-kvm-ppc-next-gku+ #2 NIP: c0000000000c73c4 LR: c0000000000c73c0 CTR: c000000000193bb8 REGS: c000000001473bc0 TRAP: 0700 Not tainted (4.17.0-kvm-ppc-next-gku+) MSR: a000000000022003 <SF,FP,RI,LE> CR: 28042884 XER: 20040000 CFAR: 0000000000000000 SOFTE: 1 GPR00: c0000000000c73c0 c000000001473e40 c000000001476700 0000000000000028 GPR04: 0000000000000001 0000000000000000 c00000000163d794 c000000001636700 GPR08: 0000000000000000 c000000000fe0c28 0000000000000000 0000000000000000 GPR12: 0000000000002000 c0000000017c0000 000000003dc5dd10 0000000002d9f7d8 GPR16: fffffffffffffffd 000000003dc5dd10 000000003e457c00 0000000000000014 GPR20: 0000000002db83a8 0000000002000000 000000002fff0000 fffffffffffffffd GPR24: 000000003dc5dd58 c000000000000000 c00000000161fc78 c000000000bb61d8 GPR28: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 NIP [c0000000000c73c4] pseries_lpar_register_process_table+0xf4/0x100 LR [c0000000000c73c0] pseries_lpar_register_process_table+0xf0/0x100 Call Trace: [c000000001473e40] [c0000000000c73c0] pseries_lpar_register_process_table+0xf0/0x100 (unreliable) [c000000001473ed0] [0000000000ef5b64] 0xef5b64 [c000000001473f60] [0000000000eeb504] 0xeeb504 [c000000001473f90] [000000000000b348] 0xb348 Instruction dump: e8010010 eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8 7c0803a6 4e800020 3c62ff94 3863e6c0 480cbe15 60000000 <0fe00000> 60000000 60000000 3c4c013b random: get_random_bytes called from print_oops_end_marker+0x40/0x80 with crng_init=0 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Attempted to kill the idle task! ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- > > Since 4.16.0 works, I could bisect down to: > > > > commit dbfcf3cb9c681aa0c5d0bb46068f98d5b1823dd3 > > Author: Paul Mackerras <paulus@xxxxxxxxxx> > > Date: Thu Feb 16 16:03:39 2017 +1100 > > > > powerpc/64: Call H_REGISTER_PROC_TBL when running as a HPT guest on POWER9 > > > > The hcall is handled by QEMU, which then calls the KVM_PPC_CONFIGURE_V3_MMU > > ioctl, which fails since PR KVM doesn't implement it, and H_REGISTER_PROC_TBL > > fails with H_PARAMETER. The panic hence come from... > > Hmmm. Maybe the kernel should check the ibm,architecture-vec-5 > property in /chosen and only register the process table if it > indicates the hypervisor can support either hash or radix. > Indeed the kernel could do that, but it is a bit unfortunate anyway for H_REGISTER_PROC_TBL(0, 0, 0, 0) to fail with H_PARAMETER, depending on the hypervisor being PR KVM or HV KVM... As an alternative, I've sent a patch for QEMU to avoid calling KVM_PPC_CONFIGURE_V3_MMU when the HPT is owned by QEMU in userspace. https://patchwork.ozlabs.org/patch/920500/ > Paul. Cheers, -- Greg
