Re: A KernelShark plugin for Xen traces analysis ​

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

On 13/04/2021 15:28, Giuseppe Eletto wrote:
> Hello,
> I want to share with you a new plugin developed by me, under the
> supervision of Dario Faggioli, which allows the new version of KernelShark
> (the v2-beta) to open and view the Xen traces created using the "xentrace" tool.
>
> In fact, KernelShark is a well known tool for graphical visualization
> Linux kernel traces, obtained via "ftrace" and "trace-cmd". Anyway thanks
> to its modular architecture, it is now possible to implement plugins which
> open and display traces with arbitrary format, for example, as in in
> this case, traces of the Xen hypervisor.
>
> For more information on how to build the plugin and/or
> to view the source code I leave the repository below:
> https://github.com/giuseppe998e/kernelshark-xentrace-plugin
>
>
> In short:
>
> $ sudo apt install git build-essential libjson-c-dev
> $ git clone --recurse-submodules
> https://github.com/giuseppe998e/kernelshark-xentrace-plugin.git
> $ cd kernelshark-xentrace-plugin/
> $ make
>
> $ export XEN_CPUHZ=3G # Sets the CPU frequency ((G)hz/(M)hz/(K)hz/hz)
> $ kernelshark -p out/ks-xentrace.so trace.xen
>
>
> 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?

There is a bug which prevents the mapping being usable in a PVH Dom0,
and I was proposing fixing it by switching to the Acquire Resource
interfaces.  A bonus of doing this is that it can be implemented on
exclusively stable hypercall interfaces, meaning that the plugin no
longer needs recompiling when you change the hypervisor.

To others on xen-devel, do we have firm statement on whether the trace
format itself is stable or not?  I think we've be somewhat nondescript
on this point in the past.

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).

~Andrew