Nicholas Piggin <npiggin@xxxxxxxxx> writes: > On Sun, 8 Apr 2018 20:17:47 +1000 > Balbir Singh <bsingharora@xxxxxxxxx> wrote: > >> On Fri, Apr 6, 2018 at 3:56 AM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: >> > This crashes with a "Bad real address for load" attempting to load >> > from the vmalloc region in realmode (faulting address is in DAR). >> > >> > Oops: Bad interrupt in KVM entry/exit code, sig: 6 [#1] >> > LE SMP NR_CPUS=2048 NUMA PowerNV >> > CPU: 53 PID: 6582 Comm: qemu-system-ppc Not tainted 4.16.0-01530-g43d1859f0994 >> > NIP: c0000000000155ac LR: c0000000000c2430 CTR: c000000000015580 >> > REGS: c000000fff76dd80 TRAP: 0200 Not tainted (4.16.0-01530-g43d1859f0994) >> > MSR: 9000000000201003 <SF,HV,ME,RI,LE> CR: 48082222 XER: 00000000 >> > CFAR: 0000000102900ef0 DAR: d00017fffd941a28 DSISR: 00000040 SOFTE: 3 >> > NIP [c0000000000155ac] perf_trace_tlbie+0x2c/0x1a0 >> > LR [c0000000000c2430] do_tlbies+0x230/0x2f0 >> > >> > I suspect the reason is the per-cpu data is not in the linear chunk. >> > This could be restored if that was able to be fixed, but for now, >> > just remove the tracepoints. >> >> Could you share the stack trace as well? I've not observed this in my testing. > > I can't seem to find it, I can try reproduce tomorrow. It was coming > from h_remove hcall from the guest. It's 176 logical CPUs. > >> May be I don't have as many cpus. I presume your talking about the per cpu >> data offsets for per cpu trace data? > > It looked like it was dereferencing virtually mapped per-cpu data, yes. > Probably the perf_events deref. Naveen has posted a series to (hopefully) fix this, which just missed the merge window: https://patchwork.ozlabs.org/patch/894757/ cheers -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
