[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