Florian Hofhammer <[email protected]> writes: > On 13/02/2026 19:36, Pierrick Bouvier wrote: >> On 2/13/26 5:38 AM, Florian Hofhammer wrote: >>> On 26/01/2026 21:46, Alex Bennée wrote:> Alex Bennée >>> <[email protected]> writes: >>>> >>>>> Florian Hofhammer <[email protected]> writes: >>>>> >>>>>> Some registers should be marked as read-only from a plugin API >>>>>> perspective, as writing to them via qemu_plugin_write_register has no >>>>>> effect. This includes the program counter, and we expose this fact to >>>>>> the plugins with this patch. >>>>>> >>>>>> Signed-off-by: Florian Hofhammer <[email protected]> >>>>>> --- >>>>>> include/qemu/qemu-plugin.h | 2 ++ >>>>>> plugins/api.c | 17 +++++++++++++++++ >>>>>> 2 files changed, 19 insertions(+) >>>>>> >>>>>> diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h >>>>>> index f976b62030..1f25fb2b40 100644 >>>>>> --- a/include/qemu/qemu-plugin.h >>>>>> +++ b/include/qemu/qemu-plugin.h >>>>>> @@ -942,11 +942,13 @@ struct qemu_plugin_register; >>>>>> * writing value with qemu_plugin_write_register >>>>>> * @name: register name >>>>>> * @feature: optional feature descriptor, can be NULL >>>>>> + * @is_readonly: true if the register cannot be written via >>>>>> qemu_plugin_write_register >>>>>> */ >>>>>> typedef struct { >>>>>> struct qemu_plugin_register *handle; >>>>>> const char *name; >>>>>> const char *feature; >>>>>> + bool is_readonly; >>>>>> } qemu_plugin_reg_descriptor; >>>>>> /** >>>>>> diff --git a/plugins/api.c b/plugins/api.c >>>>>> index fc19bdb40b..de8c32db50 100644 >>>>>> --- a/plugins/api.c >>>>>> +++ b/plugins/api.c >>>>>> @@ -403,6 +403,12 @@ bool qemu_plugin_bool_parse(const char *name, const >>>>>> char *value, bool *ret) >>>>>> * ancillary data the plugin might find useful. >>>>>> */ >>>>>> +static const char pc_str[] = "pc"; // generic name for program counter >>>>>> +static const char eip_str[] = "eip"; // x86 specific name for program >>>>>> counter >>>>>> +static const char rip_str[] = "rip"; // x86_64 specific name for >>>>>> program counter >>>>>> +static const char pswa_str[] = "pswa"; // s390x specific name for >>>>>> program counter >>>>>> +static const char iaoq_str[] = "iaoq"; // HP/PA specific name for >>>>>> program counter >>>>>> +static const char rpc_str[] = "rpc"; // microblaze specific name for >>>>>> program counter >>>>> >>>>> It's ugly but I can't think of anything better as you say in the commit >>>>> message. >>>>> >>>>>> static GArray *create_register_handles(GArray *gdbstub_regs) >>>>>> { >>>>>> GArray *find_data = g_array_new(true, true, >>>>>> @@ -417,9 +423,20 @@ static GArray *create_register_handles(GArray >>>>>> *gdbstub_regs) >>>>>> continue; >>>>>> } >>>>>> + gint plugin_ro_bit = 0; >>>>>> /* Create a record for the plugin */ >>>>>> desc.handle = GINT_TO_POINTER(grd->gdb_reg + 1); >>>>>> desc.name = g_intern_string(grd->name); >>>>> >>>>> Lets just set desc.is_readonly to false here. >>>>> >>>>>> + if (!strcmp(desc.name, pc_str) >>>>>> + || !strcmp(desc.name, eip_str) >>>>>> + || !strcmp(desc.name, rip_str) >>>>>> + || !strcmp(desc.name, pswa_str) >>>>>> + || !strcmp(desc.name, iaoq_str) >>>>>> + || !strcmp(desc.name, rpc_str) >>>>>> + ) { >>>>>> + plugin_ro_bit = 1; >>>>>> + } >>>>>> + desc.is_readonly = plugin_ro_bit == 1 ? true : false; >>>>> >>>>> And fold setting it to true into the if statement. I have a marginal >>>>> preference for g_strcmp0(desc.name, eip_str) == 0 style tests. >>>> >>>> The option of course would be to skip the register all together. Do we >>>> have code which will have multiple vaddr's for the same TB where using >>>> the TB data wouldn't be sufficient? >>> >>> Skipping the register altogether would basically make it invisible to >>> plugins and therefore remove functionality. A plugin might want to get a >>> list of all registers (which would not be complete anymore), or get the >>> current PC value. If I didn't miss anything, the latter might not >>> necessarily be possible anymore, as a callback (especially the simple >>> callback type) doesn't have access to the current TB data and can't >>> necessarily pass userdata to the callback, so it wouldn't be able to get >>> the PC from there anymore. >>> >>>>> >>>>>> desc.feature = g_intern_string(grd->feature_name); >>>>>> g_array_append_val(find_data, desc); >>>>>> } >>>>> >>>>> Otherwise: >>>>> >>>>> Reviewed-by: Alex Bennée <[email protected]> >> >> Seeing there are some questions around this, I have another one. >> >> Does it really matter if a user can read/write pc register? > > The idea of blocking writes to the PC via the register write API came up > in https://lists.gnu.org/archive/html/qemu-devel/2025-12/msg01671.html. > As it stands, writes to the PC are silently swallowed, and preventing > that could reduce confusion for plugin authors. It makes it clear why > there would be a special API for setting the PC instead of using the > generic register write API.
Agreed. > >> It seems to bring a lot of complexity to prevent this (especially >> the string per arch approach, even though that's the best we can >> do), and I'm not sure what's the actual benefit. If someone tries >> something QEMU plugins don't support in general, they can always >> send a bug report, or even a patch. >> I'm not really sure to why someone would have a bad idea mixing register >> writes and pc diversion. And if they do, it would not be surprising it >> breaks things. > > Alternatively, I could add a remark to the documentation for the > register write API that the PC can only be modified via the dedicated > API and not change the implementation at all. But I think I'll have to > defer that decision to you and Alex as the plugin subsystem > maintainers. We definitely want to make it clear to use the specific function. We just need a solution for making sure they can always find out the current pc when we have multiple virtual mappings to the same place. > >> So maybe we can just extend API with PC diversion, and not overthink too >> much about potential consequences on registers. >> >> Regards, >> Pierrick > > Best, > Florian -- Alex Bennée Virtualisation Tech Lead @ Linaro
