Closed be32826 closed 8 months ago
Previously, the block invalidation function was called on PANDA_CB_BEFORE_BLOCK_TRANSLATE, which is only triggered when both TCG caches miss (i.e. when the block is already invalidated), so I think it is a no-op.
The missing piece here is the context that we're enabling this context so that we can acquire the tb_lock
so that we can efficiently handle dropping our block from the tb cache if we fail by other means. The event that generates the block translate is most likely unrelated to the block in question.
It also seems to only invalidate the tb_jmp_cache and not tb_ctx.htable.
Those are hash tables utilized in distinct contexts: translation and runtime. I don't see an issue invalidating the htable
, but I'm not convinced it's necessary.
FWIW if we're looking for a better implementation of hooks have a look at this PR: https://github.com/panda-re/panda/pull/1187
Previously, the block invalidation function was called on
PANDA_CB_BEFORE_BLOCK_TRANSLATE
, which is only triggered when both TCG caches miss (i.e. when the block is already invalidated), so I think it is a no-op. It also seems to only invalidate thetb_jmp_cache
and nottb_ctx.htable
. I think both of these issues exist and that this PR solves them, but I'm not 100% sure.