[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Plugin Register Accesses
From: |
Alex Bennée |
Subject: |
Re: Plugin Register Accesses |
Date: |
Tue, 08 Dec 2020 22:34:06 +0000 |
User-agent: |
mu4e 1.5.7; emacs 28.0.50 |
Aaron Lindsay <aaron@os.amperecomputing.com> writes:
> 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.
Yeah probably. The current internal interface for gdb uses GByteArray's
so that may be something you pass into the read function.
>
> -Aaron
--
Alex Bennée