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". > 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. Paul.
