From: Peter Maydell <peter.maydell@linaro.org>
To: Kenneth Adam Miller <kennethadammiller@gmail.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>, qemu-devel@nongnu.org
Subject: Re: Access target TranslatorOps
Date: Wed, 20 Jul 2022 18:37:23 +0100 [thread overview]
Message-ID: <CAFEAcA8sWMD1eZCZyiMPz_SNKRn6J--Gm53aQuTo-KO5bWyFrQ@mail.gmail.com> (raw)
In-Reply-To: <CAK7rcp-Ts=3JNoYRak-Zddb0NDjdgSqbGD32xFEguw0yLqydyw@mail.gmail.com>
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
next prev parent reply other threads:[~2022-07-20 17:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 19:37 Access target TranslatorOps Kenneth Adam Miller
2022-07-20 8:44 ` Alex Bennée
2022-07-20 16:37 ` Kenneth Adam Miller
2022-07-20 17:37 ` Peter Maydell [this message]
2022-07-22 5:08 ` Kenneth Adam Miller
2022-07-22 9:18 ` Alex Bennée
2022-07-22 13:48 ` Kenneth Adam Miller
2022-07-22 14:38 ` Alex Bennée
2022-07-25 9:07 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAFEAcA8sWMD1eZCZyiMPz_SNKRn6J--Gm53aQuTo-KO5bWyFrQ@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=kennethadammiller@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).