Re: [PATCH v3 2/5] plugins: add read-only property for registers

["Alex Bennée" <alex.bennee@linaro.org>]

Florian Hofhammer <florian.hofhammer@epfl.ch> 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 <alex.bennee@linaro.org> writes:
>>>>
>>>>> Florian Hofhammer <florian.hofhammer@epfl.ch> 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 <florian.hofhammer@epfl.ch>
>>>>>> ---
>>>>>>   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 <alex.bennee@linaro.org>
>> 
>> 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