Re: Access target TranslatorOps

From: Kenneth Adam Miller <kennethadammiller@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: Access target TranslatorOps
Date: Fri, 22 Jul 2022 01:08:58 -0400	[thread overview]
Message-ID: <CAK7rcp8pvQfn=x1DsFwmr2GbK-tqmCxh8stkA8+QmfdC-peXPA@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA8sWMD1eZCZyiMPz_SNKRn6J--Gm53aQuTo-KO5bWyFrQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2637 bytes --]