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

["Emilio G. Cota" <cota@braap.org>]

On Mon, Oct 29, 2018 at 12:48:05 +0300, Pavel Dovgalyuk wrote:
> > From: Emilio G. Cota [mailto:cota@braap.org]
> > - 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.

I'd provide an API call to get those up to date, since the common
case is that callbacks won't require those to be up to date.

> > - 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"?

That's certainly not my intention.

I'd only export common ops that are trivial to implement,
whether with TCG or whatever we use in 100 years time. I think
incrementing a counter is a good use of this; letting plugins
go wild by exporting a "TCG-like API" is not at all the
point. Users that demand that can be just told to fork QEMU.

Thanks,

		Emilio