Re: [PATCH 1/2] KVM: PPC: Book3S HV: trace_tlbie must not be called in realmode

On Tue, 10 Apr 2018 11:25:02 +0530
"Naveen N. Rao" [off-list ref] wrote:

Michael Ellerman wrote:

quoted

Nicholas Piggin [off-list ref] writes:
  

quoted

On Sun, 8 Apr 2018 20:17:47 +1000
Balbir Singh [off-list ref] wrote:
 

quoted

On Fri, Apr 6, 2018 at 3:56 AM, Nicholas Piggin [off-list ref] wrote:  

quoted

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.
 

quoted

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/  

I'm afraid that won't actually help here :(
That series is specific to the function tracer, while this is using 
static tracepoints.

We could convert trace_tlbie() to a TRACE_EVENT_CONDITION() and guard it 
within a check for paca->ftrace_enabled, but that would only be useful 
if the below callsites can ever be hit outside of KVM guest mode.

Right, removing the trace points is the right thing to do here.

Doing tracing in real mode would be a whole effort itself, I'd expect.
Or disabling realmode handling of HPT hcalls if trace points are
active.

Thanks,
Nick