Re: Qemu TCG Plugins - how to access guest registers?

[Benjamin <benjamin@thatjames.org>]

[-- Attachment #1: Type: text/plain, Size: 4855 bytes --]

Thanks for your quick response.

On Mon, Mar 30, 2020 at 9:15 AM Alex Bennée <alex.bennee@linaro.org> wrote:

>
> Lukas Straub <lukasstraub2@web.de> 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
>   operations.
>
> 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
> guidelines.
>
> 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.


> --
> Alex Bennée
>

Thanks

[-- Attachment #2: Type: text/html, Size: 5965 bytes --]