Re: [RFC PATCH v3 01/11] plugins: add types for callbacks related to certain discontinuities

["Julian Ganz" <neither@nut.email>]

Hi Pierrick,

December 6, 2024 at 12:03 AM, "Pierrick Bouvier" wrote:
> On 12/5/24 13:50, Julian Ganz wrote:
> >  If you cannot rely on an input being a sensible value, doesn't that
> >  render the input useless?
> > 
> I agree. If for a specific event it's impossible to provide a value (i.e. the value has no meaning for a real cpu), it will just point that we need several types of data per event, and the compromise of having a single callback won't be possible.
> 
> We should differentiate "it's hard to find this value in QEMU" vs "this value does not exist in real life". The first can be solved if we put effort into it. And every time a cpu changes it's flow of execution, it makes sense to find where it was just before.
> 
> One of the end goals is to be able to build a full control flow graph, with edges labeled on transition type (exceptions, traps, interrupts, jump, fallback), which we can do with the triple {event,from,to}.

I agree that that triple is sensible for any event type and likely
useful to plugin authors. At least if the semantics are sufficiently
uniform among event types. However, I also feel that given the actual
implementation (hooks sprinkled over target specific code) this is not
easily achievable reliably. At least testability should be a hard
requirement. Otherwise the API's reliability will inevitably deteriorate
over time without any way to tell how bad the situation got.

> > > Let's try to move forward, and solve the problems we have with from_pc. The testing part can be solved already (as explained in a previous message). In which cases can't you identify from_pc?
> > > 
> >  I'll have to check, but problems that I discussed with a colleague
> >  included jumps to an unmapped page resulting in the appropriate
> >  exception. We ultimately agreed that in such a situation from_pc should
> >  point to the jump target inside the unmapped page, instead of, say, the
> >  jump. We assume that most targets should already behave this way without
> >  further changes. However, in order to compute the correct from_pc, we
> >  need to know the jump target before the exception is raised (i.e. right
> >  after the jump instruction is executed), and that's not necessarily
> >  straight-forward to do in a plugin.
> > 
> It's an interesting conversation. For the scope of this series, I agree you should use the jump target, which triggered the trap.
> 
> In fine, transitions should simply follow what the cpu does.
> 
> - orig_insn: jump to A
> - jump_target: execute A traps
> - page_fault: load page
> - jump_target: come back to A
> 
> event(JUMP, orig_insn, jump_target) // not covered by this series
> event(EXCEPTION, jump_target, page_fault)
> ... execute page_fault (with potential other transitions)
> event(JUMP, end_page_fault, jump_target)
> 
> In the case of a double trap, we could follow the same logic, and represent the original transition that lead to the trap, and the two consecutive traps.
> 
> Does it make sense?

Yes, those transitions are correct imo. And if a jump event should be
introduced at some point, the call sequence would look like that. My
issue is that testing this (in a plugin) will not be straight forward
or even impossible. And overly complex tests don't exactly provoke
confidence.

Regards,
Julian Ganz