Re: trace_FOO_tcg bit-rotted?

[Alex Bennée]

"Vilanova, Lluis" <vilanova@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 <stefanha@redhat.com> writes:
>> 
>> > On Mon, Apr 12, 2021 at 08:06:57PM +0100, Alex Bennée wrote:
>> > > 
>> > > Stefan Hajnoczi <stefanha@redhat.com> writes:
>> > > 
>> > > > On Fri, Apr 09, 2021 at 05:29:08PM +0100, Alex Bennée wrote:
>> > > > > 
>> > > > > Laurent Vivier <laurent@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