Re: [RFC PATCH v2 0/7] tcg-plugins: add hooks for interrupts, exceptions and traps

[Pierrick Bouvier <pierrick.bouvier@linaro.org>]

On 10/23/24 09:12, Julian Ganz wrote:
> Hi, Pierrick,
> 
> October 23, 2024 at 5:16 PM, "Pierrick Bouvier" wrote:
>>
>> Hi Julian,
>>
>> On 10/23/24 05:56, Julian Ganz wrote:
>>
>>>   October 22, 2024 at 11:15 PM, "Pierrick Bouvier" wrote:
>>>
>>>>
>>>> On 10/22/24 01:21, Julian Ganz wrote:
>>>>
>>>
>>>   Ok, I'll introduce an enum and combine the three callbacks in the next
>>>   iteration then.
>>>   typedef struct {
>>>   enum qemu_plugin_cf_event_type ev;
>>>   union {
>>>   data_for_interrupt interrupt;
>>>   data_for_trap trap;
>>>   data_for_semihosting semihosting;
>>>   } qemu_plugin_cf_event;
>>>   /* data_for_... could contain things like from/to addresses, interrupt id, ... */
>>>
>>>   I don't think this is a good idea.
>>>   Traps are just too diverse, imo there is too little overlap between
>>>   different architectures, with the sole exception maybe being the PC
>>>   prior to the trap. "Interrupt id" sounds like a reasonably common
>>>   concept, but then you would need to define a mapping for each and every
>>>   architecture. What integer type do you use? In RISC-V, for example,
>>>   exceptions and interrupt "ids" are differentiated via the most
>>>   significant bit. Dou keep that or do you zero it? And then there's
>>>   ring/privilage mode, cause (sometimes for each mode), ...
>>>
>>>>
>>>> I didn't want to open the per architecture pandora box :).
>>>>   I don't think the plugin API itself should deal with per architecture
>>>>   details like meaning of a given id. I was just thinking to push this "raw" information to the plugin, that may/may not use architecture specific knowledge to do its work. We already have plugins that have similar per architecture knowledge (contrib/plugins/howvec.c) and it's ok in some specific cases.
>>>>
>>>   But how would such an interface look? The last PC aside, what would you
>>>   include, and how? A GArray with named items that are itself just opaque
>>>   blobs?
>>>
>> I was not thinking about a new interface for this. Having the "raw" interrupt id is enough for a plugin to do useful things, by having knowledge of which architecture it's instrumenting.
> 
> But what is would the "raw" interrupt id even be for a given
> architecture? I don't think you can answer this question with "obviously
> this _one_ integer" for all of them.
>

Choosing interrupt id as an example of what we want to include was 
confusing, and brought more conversation than I expected.

I wanted to point that we may want different data per event, instead of 
talking specifically of interrupt or per architecture specific data.
To still answer you, I was thinking sharing interrupt number for x86_64, 
or interrupt id for aarch64. It's probably too naive, so let's drop this 
and move on :).

>>>
>>> And what would be the benefit compared to just querying the respective
>>>   target specific registers through qemu_plugin_read_register? Which btw.
>>>   is what we were going to do for our use-case. Even the example you
>>>   brought up (howvec) uses querying functions and doesn't expect to get
>>>   all the info via parameters.
>>>
>> You're right, but it's because it's querying instruction data.
>> I may be wrong on that, but at translation time, we may or may not be interested in accessing tb/insn data.
>>
>> However, for control flow analysis, beyond a simple counting plugin, we probably want to access further data almost everytime.
>>
>> I see it closer from syscall instrumentation, which pushes the syscall id, and all register values, instead of letting the user poke it. Makes more sense compared to that?
> 
> Yes, but then you are in "GArray of named, potentially complex value"
> terretory again. And the comparison with syscalls also falls apart when
> you consider that, for syscalls, they are well defined and enumerated
> identically for at least a variety of targets, while the same kind of
> "enumeration", if it even exists, is in completely different order for
> every architecture.
> 

We can restrict to having from/to PCs for now. Mentioning interrupt id 
as example was a mistake.

>>>
>>>>
>>>> But having something like from/to address seems useful to start. Even if we don't provide it for all events yet, it's ok.
>>>>
>>>   Yes, I certainly see the advantages of having either the last PC or the
>>>   would-be-next PC as they are sufficiently universal. You can usually
>>>   retrieve them from target-specific registers, but that may be more
>>>   complicated in practice. In the case of RISC-V for example, the value
>>>   of the EPC differs between interrupts and exceptions.
>>>
>> To the opposite of interrupt id, a PC is something universal by definition, and with a single meaning across architecture. However, accessing it by name varies per architecture, and even per sub events, as you are stating for RISC-V.
> 
> Yes. And for that very reason I would not pass "the EPC" to a callback
> but a clearly, target agnostic, defined value such as:
> 
> | The PC of the instruction that would have been executed next, were it
> | not for that event
> 
> or
> 
> | The PC of the instruction that was executed befroe the event occurred
> 
> And unlike interrupt ids, the plugin API already has a precedent for
> what type to use: uint64_t
>

Looks good. As said in previous message, we can drop the complex data 
type idea.

So we could have something like:

/* plugin side */
void on_cf_event(qemu_plugin_cf_event_type, uint64_t from, uint64_t to) {
    ...
}

/* API side */
void qemu_plugin_register_vcpu_syscall_cb(
qemu_plugin_id_t id, qemu_plugin_cf_event_type type, 
qemu_plugin_register_vcpu_cf_cb);

We thus would have a new callback type qemu_plugin_vcpu_cf_cb_t added.

For registering several events, we might define enum values for types 
indexed on every bit, so we can directly xor the enum to register 
several types. (same idea than existing qemu_plugin_mem_rw, but for more 
values, with a specific ALL value covering all possibilities).

Does that match what you were thinking?

> Regards,
> Julian