[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 12:17:27 +0000 |
User-agent: |
mu4e 1.5.7; emacs 28.0.50 |
Aaron Lindsay <aaron@os.amperecomputing.com> writes:
> I'm trying to migrate to using the new plugin interface. I see the
> following in include/qemu/qemu-plugin.h:
>
>> enum qemu_plugin_cb_flags {
>> QEMU_PLUGIN_CB_NO_REGS, /* callback does not access the CPU's regs */
>> QEMU_PLUGIN_CB_R_REGS, /* callback reads the CPU's regs */
>> QEMU_PLUGIN_CB_RW_REGS, /* callback reads and writes the CPU's regs */
>> };
>
> But I don't see a way to access registers in callbacks. Am I missing
> something?
No - while those symbols do inform the TCG to not try and optimise
the register file we don't yet have an API for the plugins for reading
(or writing) the CPU registers.
There has been discussion about this before, I'll quote what I said
off-list to someone else who asked:
> Has there been any clarification or softening of the position that
> exposing register and memory contents to the QEMU plugin would provide a
> way to circumvent the GPL of QEMU?
I don't think implementing read only access would be a problem and
should probably be a first step anyway.
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).
Memory is a little trickier because you can't know at any point if a
given virtual address is actually mapped to real memory. The safest way
would be to extend the existing memory tracking code to save the values
saved/loaded from a given address. However if you had register access
you could probably achieve the same thing after the fact by examining
the opcode and pulling the values from the registers.
>
> -Aaron
--
Alex Bennée