On Fri, Jun 14, 2013 at 3:01 PM, David Ahern <dsah...@gmail.com> wrote:
> On 6/14/13 3:53 PM, Cody P Schafer wrote:
>>
>> On Thu, Jun 13, 2013 at 6:10 PM, David Ahern <dsah...@gmail.com> wrote:
>>>
>>> On 6/13/13 7:04 PM, Cody P Schafer wrote:
>>>>
>>>> Hi all, I'm trying to use perf kvm to profile linux early boot.
>>>>
>>>> However, perf kvm top always appears to behave as though it's in
>>>> non-callgraph mode.
>>>
>>> During event collection perf kernel side does not walk the guest
>>> callchain.
>>> I believe it only collects IP.
>>>
>>
>> Some further investigation shows that the user unwind code could be
>> used, but [the following] is always false.
>>      if (!((evsel->attr.sample_type & PERF_SAMPLE_REGS_USER) &&
>>           (evsel->attr.sample_type & PERF_SAMPLE_STACK_USER)))
>>                return 0;
>>
>> There don't appear to be any users which _set_ PERF_SAMPLE_REGS_USER
>> or PERF_SAMPLE_STACK_USER, only ones that check it. Can we just use
>> __perf_evsel__set_sample_bit() twice and have this magically work?
>>
>> So, a few questions:
>>   - can we get perf to dump the user regs & stack for kvm guest kernels?
>>   - does the in kernel stack unwinding _only_ trigger for host (ie:
>> real) kernel mode samples? If so, does this restriction always make
>> sense?
>>   - How did all this user unwind code get triggered if no one is
>> setting PERF_SAMPLE_REGS_USER and PERF_SAMPLE_STACK_USER? Was it ever
>> triggered?
>>
>
> I am under the impression the limitations are these 2 snippets in
> arch/x86/kernel/cpu/perf_event.c:

Yep, that's disabling the in-kernel callchain generation (the in-perf
callchain code should still be an option without this). I wonder if
one could use perf_callchain_user() to find the callchain of the guest
kernel.

Does anyone know the particular changes that need to be done to
support kvm backtraces/the reasons it is specifically disabled?
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to