Re: [Qemu-devel] [RFC 00/48] Plugin support

[Pavel Dovgalyuk]

> From: Emilio G. Cota [mailto:address@hidden
> - 2-pass translation. Once a "TB translation" callback is called,
>   the plugin must know the span of the TB. We should not
>   force plugins to guess where the TB will end; that is strictly
>   QEMU's job, and can change any time. A TB is thus a sequence
>   of instructions of whatever length the particular QEMU
>   implementation decides. Thus, for each TB, a 3-step process
>   is followed: (1) the plugin layer keeps a copy of the contents
>   of the current TB, (2) once the TB is well-defined, its
>   descriptor and contents are passed to plugins, which then
>   register their desired instrumentation (e.g. "call me back
>   on this particular instruction", or "call me back when
>   the whole TB executes"); note that plugins can use a disassembler
>   like capstone to decide what to do with each instruction; they
>   can also allocate memory and then get a pointer to it passed
>   back from the callbacks. And finally, (3) the target translator
>   is called again to generate the final instrumented translated TB.
>   This is what I called the "2-pass translation", since we go
>   twice over the translation loop in translator.c. Note that the
>   2-pass approach has virtually no overhead (0.40% for SPEC06int);
>   translation is much cheaper than execution. But anyway, if no
>   plugins have subscribed to TB translation, we only do one pass.

Can plugin affect the translation somehow to force flushing cached registers?
E.g. callback may need correct EFLAGS which usually does not updated
until the end of the block.

> - Support for inlining instrumentation. This is done via an
>   explicit API, i.e. we do not export TCG ops, which are internal
>   to QEMU. For now, I just have support for incrementing a u64
>   with an immediate, e.g. to increment a counter.

It means that we'll have "yet another one TCG"?

Pavel Dovgalyuk