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
