Re: A KernelShark plugin for Xen traces analysis ​

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 14/04/2021 18:31, Dario Faggioli wrote:
> On Tue, 2021-04-13 at 16:33 +0100, Andrew Cooper wrote:
>> On 13/04/2021 15:28, Giuseppe Eletto wrote:
>>> You will need the development version of KernelShark, available
>>> here:
>>> https://git.kernel.org/pub/scm/utils/trace-cmd/kernel-shark.git
>>>
>>> A screenshot of the plugin in action is available here:
>>> https://github.com/giuseppe998e/kernelshark-xentrace-plugin/raw/master/.github/img/ks-xentrace.png
>>>
>>> I'm happy to receive whatever feedback you may have about it,
>>> and to answer any question.
>> Very nice.
>>
>> A couple of questions.  Which Xen libraries do you currently use map
>> the
>> frames?
>>
> Err... If I understood the question none, as the plugin loads and
> parses a file, as it is produced by `xentrace`. :-)
>
> But maybe I didn't understand the question?

Ah no - that answer's my question.  I'd blindly assumed that the plugin
was talking directly to Xen to obtain the tracebuffer.

>> For the screenshot, there are a lot of examples where you have a
>> dom:vcpu pair, and a number rendered in hex.  Throughout the
>> hypervisor,
>> we're standardising on d$v$ as a format, and e.g. d[IDLE]v$ for some
>> of
>> the magic domid's (0x7ff0 ... 0x7fff).
>>
> Yes, the content of the "info" column is currently a bit "raw". I
> believe it should be made more similar to what `xenalyze --dump-all`
> looks like, rather than to what xentrace_format` does (just to make and
> example that people that have used these two tools can understand).
>
> This is just due to the fact that we wanted to let the Xen and
> KernelShark communities know about this work as soon as Giuseppe got it
> working properly and reliably, to gather any kind of feedback, decide
> where this should live, in the long run, (in Xen? In KS? In its own
> project?), etc. :-)

Where the plugin (ought to) live depends heavily on whether we consider
the trace format a stable ABI or not.

~Andrew