Peter Maydell writes: > On 15 September 2017 at 14:39, Lluís Vilanova <vilan...@ac.upc.edu> wrote: >> Peter Maydell writes: >>> This looks like it's exposing too much implementation detail. >>> We should just provide an API for "hook to be called for >>> memory writes" which gets all the information when it >>> is called. I don't think we should expose any kind of >>> "this hook is called at translation time" at all. >> >> The differentiation between translation-time and execution-time is key to >> perform certain analysis efficiently.
> It's also exposing internal QEMU implementation detail. > What if in future we decide to switch from our current > setup to always interpreting guest instructions as a > first pass with JITting done only in the background for > hot code? TCI still has a separation of translation-time (translate.c) and execution-time (interpreting the TCG opcodes), and I don't think that's gonna go away anytime soon. Even if it did, I think there still will be a translation/execution separation easy enough to hook into (even if it's a "fake" one for the cold-path interpreted instructions). > Sticking to instrumentation events that correspond exactly to guest > execution events means they won't break or expose internals. It also means we won't be able to "conditionally" instrument instructions (e.g., based on their opcode, address range, etc.). Of course we can add the translation/execution differentiation later if we find it necessary for performance, but I would rather avoid leaving "historical" instrumentation points behind on the API. What are the use-cases you're aiming for? Cheers! Lluis
