"Vilanova, Lluis" <vilan...@imperial.ac.uk> writes:
> El dt. 13 de 04 de 2021 a les 10:25 +0100, en/na Alex Bennée va > escriure: >> Stefan Hajnoczi <stefa...@redhat.com> writes: >> >> > On Mon, Apr 12, 2021 at 08:06:57PM +0100, Alex Bennée wrote: >> > > >> > > Stefan Hajnoczi <stefa...@redhat.com> writes: >> > > >> > > > On Fri, Apr 09, 2021 at 05:29:08PM +0100, Alex Bennée wrote: >> > > > > >> > > > > Laurent Vivier <laur...@vivier.eu> writes: >> > > > > >> > > > > > Le 06/04/2021 à 18:00, Alex Bennée a écrit : >> > > > > > > Hi, >> > > > > > > >> > > > > > > It's been awhile since I last played with this but I >> > > > > > > think we are >> > > > > > > suffering from not having some test cases for tracing >> > > > > > > code >> > > > > > > generation/execution in the tree. I tried adding a simple >> > > > > > > trace point to >> > > > > > > see if I could track ERET calls: >> <snip> >> > > > >> > > > Lluís: are you happy to deprecate tcg trace events in favor of >> > > > TCG >> > > > plugins? >> <snip> >> > >> > That said, I haven't used the TCG trace event functionality and >> > maybe >> > I'm missing something obvious that Lluís will point out :). >> >> I've updated the Cc to what I think is Lluís current email as I was >> getting bounces from the old academic address. > > Hi folks, long time no write; thanks for tracking me down :) > > I think it'd be great to deprecate TCG tracing in favour of the plugin > interface, pushing some of the burden out of qemu. > > I haven't measured the performance of the plugin interface, but AFAIR > TCG trace prints also use TCG helpers, so there should not be a lot of > difference. Pretty much. The only real difference is we don't have plugins enabled by default as there is a small impact when no plugins are used do to the insertion of dummy callbacks during code generation. We do this to avoid a double-pass later. > As Stefan pointed out, this means plugin writers will have to write > their own TCG tracing code. Hopefully, the plugin API can be extended > to integrate with qemu's logging backend (it seems qemu_plugin_outs > goes somewhere else), qemu_plugin_outs goes out via the logging backend - but not the tracing subsystem. Do you think being able to emit tracepoints to simpletrace or the dtrace/ftrace would be a useful extension to the API. > and common plugins can be kept on a separate repo > under the qemu umbrella for easier reuse (e.g., to provide the same > functionality as TCG tracing). Currently we have two areas in QEMU, tests/plugins which are very basic and used in check-tcg to exercise the code and contrib/plugins where the meatier plugins are defined. I'm happy (and encourage!) more to be added there. Do you have any documented uses of the trace subsystem that I could re-implement in TCG plugins by way of example? I have the feeling it has been used for academic papers but I haven't seen usage "in the wild". > > > Cheers, > Lluis -- Alex Bennée
