qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 0/6] initial plugin support


From: Emilio G. Cota
Subject: Re: [Qemu-devel] [RFC 0/6] initial plugin support
Date: Tue, 26 Sep 2017 12:15:38 -0400
User-agent: Mutt/1.5.24 (2015-08-30)

On Tue, Sep 26, 2017 at 06:22:31 +0200, Thomas Huth wrote:
> Sorry for my ignorance, but if you send a patch series like this, could
> you please elaborate a little bit more on the topic what this all is
> about? In this cover letter, you basically give only some pointers about
> other patch series and point the reader to patch 2, but also patch 2
> does not really have a proper *description* of what this is really all
> about. Sure, it's about plugins, but what kind of plugins? Audio? Video?
> CPU? Everything? If you send RFC, you should properly describe your
> vision first, and maybe give some examples, before you jump into the
> details.

On Tue, Sep 26, 2017 at 06:27:01 +0200, Thomas Huth wrote:
> If you introduce new .c files, please add some sentences with a proper
> description in the header with some very high level description about
> what the code in the file is supposed to be doing. Just reading "plugin
> interface" is not really very helpful when trying to understand new code.

You make very good points.

It was an RFC aimed mostly at people who had been following the previous
threads on this topic. However, I understand people who had not followed
those threads lacked the necessary context. Sorry about that.

As Stefan pointed out, the goal is to provide some sort of instrumentation
a la Pin/DynamoRIO. The extent of said instrumentation is still to be decided,
although we agree on that at least we should be able to "instrument" (i.e.
observe via callbacks) instructions executed and memory accesses in the guest.

Currently I'm working bottom-up on this; my goal is to simulate an ARMv8
system, so for that I need to feed the instruction stream and memory accesses
to the timing model. This could be done in different ways, so I'll evaluate
the alternatives to see how they affect performance.

Note that plugin (or instrumentation) support has been implemented in the
past. However, this was for academic projects and the code was never submitted
to the list. Some examples:
- QTrace
  code: https://github.com/x-y-z/QTRACE
  paper: http://ieeexplore.ieee.org/document/7095810/ (paywall)
- Decaf
  code: https://github.com/sycurelab/DECAF
  paper: http://www.cs.ucr.edu/~heng/pubs/issta14.pdf
- QSim
  code: https://github.com/gtcasl/qsim
  paper: http://ieeexplore.ieee.org/abstract/document/6429075/ (paywall)
- PEMU
  code: https://github.com/utds3lab/pemu
  paper: http://www.utdallas.edu/~zxl111930/file/VEE15.pdf
- ESESC
  code: https://github.com/masc-ucsc/esesc
  paper: https://users.soe.ucsc.edu/~renau/docs/hpca13.pdf

Thanks,

                Emilio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]