Re: Plugin Register Accesses

[Aaron Lindsay]

On Dec 08 17:56, Alex Bennée wrote:
> Aaron Lindsay <aaron@os.amperecomputing.com> writes:
> > On Dec 08 12:17, Alex Bennée wrote:
> >>   For registers I think there needs to be some re-factoring of QEMU's
> >>   internals to do it cleanly. Currently we have each front-end providing
> >>   hooks to the gdbstub as well as building up their own regid and xml to
> >>   be consumed by it. We probably want a architectural neutral central
> >>   repository that the front ends can register their registers (sic) and
> >>   helpers with. This would then provide hooks for gdbstub to cleanly
> >>   generate XML as well as an interface point for the plugin infrastructure
> >>   (and probably whatever the HMP uses as well).
> >
> > In a previous incarnation, I was proxying calls to the plugin API
> > directly through to gdb_read_register() in gdbstub.c and therefore using
> > gdb as the point of commonality. I'm not saying it's ideal but... it
> > works? One downside is that you have to know 'out-of-band' which integer
> > value corresponds to the register you want to query for your
> > architecture, though it hasn't been a significant issue for me.
> 
> Certainly workable for a private branch but I don't want to merge
> anything like that upstream.

Sure - I was more commenting on what I've done in case it's useful than
pushing for it to be upstreamed!

> As far as I can see there are a number of
> consumers of register information:
> 
>   - plugins
>   - gdbstub
>   - monitor (info registers)
>   - -d LOG_CPU logging
> 
> so rather than have them all have their hooks into every front-end I can
> see a case for consolidation.
> 
> For the plugin case providing an introspection helper to get a handle on
> the register makes sense and would be less painful than teachning
> plugins about gdb regids which can and do move around with new system
> registers.
> 
>   qemu_plugin_reg_t *handle = qemu_plugin_find_register("x2")
> 
> if we document the handle as usable across calls this can be done on
> start-up. Then it would be:
> 
>   uint64_t val = qemu_plugin_read_register(cpu_index, handle);

I recognize this is pseudocode, but I'm wondering "out loud" if this
would need to be variable-width instead of a uint64_t to allow for wider
registers in an actual implementation.

-Aaron