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

[Julian Ganz]

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