Thanks for your quick response.
Lukas Straub <address@hidden> writes:
>> My question is, how do I access the guest memory and registers from the
>> plugin callback function? The API seems to indicate that it is possible,
>> since the callback registering requires you to say if you will access them,
>> and if it's RW or just read.
Currently we document what plugins can do in docs/devel/tcg-plugins.rst:
TCG plugins are unable to change the system state only monitor it
passively. However they can do this down to an individual instruction
granularity including potentially subscribing to all load and store
This was a conscious decision to avoid plugins being used as an end-run
around the GPL to implement proprietary out-of-tree extensions.
That is not to say we might relax the rules in the future - it was a
topic of discussion at the maintainers summit and we wanted to document
some guidelines around interfacing with QEMU so people didn't get the
wrong idea about what these APIs provide (c.f. multi-process qemu and
vhost-user which could also be abused in similar ways).
I understand restricting the API so that the system state cannot be changed, only inspected. I should have been more specific in my question.
I am attempting to create a plugin that tracks all memory accesses, so I can emulate cache behavior. The reason I would like to read the registers, is because many load/store instructions depend on register values, which I can only be sure of at run-time.
Some of the concepts you mentioned I am not very familiar with; I am simply emulating an ARM A9 processor in bare-metal mode, to give you a point of reference of my use case.
Indeed Emilio's original tree did contain these more invasive hooks and
while we deliberate upstream it will hopefully not be as hard to
maintain a light out-of-tree fork should you need such functionality now.
Could you please point me towards this tree? I haven't run across it yet in my investigating of all of this.
>> Are there any examples of using this part of the API? I realize this is a
>> very new part of Qemu functionality.
So far the examples represent the totality of the API that has been
exercised and I'm keen we add more as new extensions to the API are
added. As to the specific question about accessing register values that
is exactly down to the newness of the API.
Register access is a tricky problem because of the fact that QEMU
supports so many guest architectures. I wasn't keen on slapping in a
functional but ugly API that hard-coded values like gdb register ids so
I left it out for the time being. I'd happily accept patches to add that
functionality assuming it meets the projects quality and taste
Some approaches we could take include:
- hook into tcg_global_*_new and allow plugin to introspect registers
- hook into gdbstub in some way
The first approach elides over the fact that a lot of registers aren't
actually known to the TCG - pretty much all vector registers tend to be
loaded into anonymous TCG temps as we go. Maybe this could just be fixed
by just providing a few more registrations functions at the start even
if the TCG itself wouldn't use that knowledge.
The gdbstub provides a lot more visibility of register state and for
some architectures this can be quite comprehensive - for example in
system mode you can access pretty much every ARM co-processor register.
However the gdb interface is a little clunky as there are a lot of magic
register id numbers and the canonical way to enumerate this is to chew
through a bunch of XML that each target generates (see
gdb_register_coprocessor). I'm not keen on exposing that pile of XML via
the register interface. Maybe there is scope to improve our internal
APIs so the enumeration of registers can be handled by helpers that
record mappings and ids and generate the XML for the gdbstub centrally?
There may be other approaches we could take and I'm open to suggestions.
I'd be happy to look into ways to implement this functionality. However, I just started using Qemu this year, so these things sound like they would have a steep learning curve for me.
The gdbstub approach seems like it would provide the most introspection ability. What would you suggest as a starting point for looking into this?
All of this being said, if you think my project is too complicated, to implement a cache emulator with TCG plugins, then I could always try just hacking together some custom helper functions.