qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Access target TranslatorOps


From: Kenneth Adam Miller
Subject: Re: Access target TranslatorOps
Date: Fri, 22 Jul 2022 01:08:58 -0400

I need to determine the set of instruction encodings that the TCG can support for a given platform. I am not bothered whether the target runs at all, and in fact it is better if it doesn't, so runtime or translate time doesn't bother me.

Imagine I were adding support for more instructions for a given platform. I would like to check that I'm using the API right. It's amazing that it's been so far and there's no way to check that the correct behavior occurs when a given encoding is encountered regarding the TCG. A boolean result from a can_translate called just when the target encounters the instruction would be good. Additionally, the ability to force the translation of arbitrary encodings would be good. I would like to not have to engineer some binary file format.

On Wed, Jul 20, 2022 at 1:37 PM Peter Maydell <peter.maydell@linaro.org> wrote:
On Wed, 20 Jul 2022 at 17:39, Kenneth Adam Miller
<kennethadammiller@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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]