On Wed, 20 Jul 2022 at 17:39, Kenneth Adam Miller <kennethadammil...@gmail.com> wrote: > That I know of, the TCG plugins do not allow me to feed the > QEMU instance dynamically changing opcodes. I wouldn't use > TranslatorOps if I don't have to. I want to facilitate a > use case in which the contents of the target being emulated > are changing, but it is not a self modifying target. I have > to query and interact with the TCG to find out what opcodes > are supported or not.
I agree that feeding opcodes into the translator isn't what TCG plugins are intended for. I'm definitely not clear on what you're trying to do here, so it's hard to suggest some other approach, but linux-user code shouldn't be messing with the internals of the translator by grabbing the TranslatorOps struct. Among other things, linux-user code is runtime and TranslatorOps is for translate-time. Sometimes code in linux-user needs to be a bit over-familiar with the CPU state, but we try to keep that to a minimum. Generally that involves code in target/foo/ providing some set of interface functions that code in linux-user/foo/ can work with, typically passing it the CPU state struct. thanks -- PMM
