qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Benjamin <benjamin@thatjames.org>
Cc: Lukas Straub <lukasstraub2@web.de>,
	"Emilio G . Cota" <cota@braap.org>,
	qemu-devel@nongnu.org, qemu-discuss@nongnu.org
Subject: Re: Qemu TCG Plugins - how to access guest registers?
Date: Wed, 01 Apr 2020 09:00:11 +0100	[thread overview]
Message-ID: <871rp7fxf8.fsf@linaro.org> (raw)
In-Reply-To: <CAOragkwi-s7PvDEMB-OKF1s-N3D7caASOjWKJsQFmCu2bTvCaA@mail.gmail.com>


Benjamin <benjamin@thatjames.org> writes:

<snip>
>>
>> You don't need the registers at that point because at run time QEMU will
>> have already resolved the address and will pass it via the
>> qemu_plugin_register_vcpu_mem_cb. The hotpages and mem plugin examples
>> demonstrate the use of the API.
>>
>
> The way you explained this, although it might seem simple, really helped me
> understand better the level at which the TCG plugins operate.
> I went and changed my code to be more based on the code in hotpages.c, and
> it is much simpler now.
> I'm going to go look at that Dinero Cache Simulator you linked to see if I
> can get any ideas on how to improve my cache code.

Glad it was of help ;-)
>> > All of this being said, if you think my project is too complicated, to
>> > implement a cache emulator with TCG plugins, then I could always try just
>> > hacking together some custom helper functions.
>>
>> As I said above I don't think you need register values to do cache
>> emulation as you have the addresses. You will need to decode some of the
>> cache management instructions though. Fortunately you can do that at
>> translation time and only instrument the ones you need. See howvec for
>> examples.
>>
>
> I'm not familiar with cache management instructions.  What exactly do you
> mean by that?  It sounds like something that would be dependent on the
> guest architecture.
> Or maybe it's things like pre-fetching hints?  Then the plugin would need
> to take into account cache latencies, something my code doesn't deal with
> right now.

There are architecture dependent instructions that do things like flush
d and icaches. As QEMU doesn't expose those semantics to the plugin
(behaviour is very specific to each guest architecture) then the plugin
would have to deal with it itself. You would do this by checking each
translated instruction and inserting a call back in front of those that
do cache operations to make whatever internal changes you need to do
inside of the plugin.

> I would be glad to share my implementation once it's in a better working
> state.
> Where can I find guidelines on the coding standard expected of QEMU
> software?
> Thanks

CODING_STYLE.rst in the top level of the source tree is the canonical
document. Also "make check-tcg" will include a plugin test for each
plugin in the tree for each test (assuming you have compilers available
for each guest architecture - see docs/devel/testing.rst).

Good luck!

-- 
Alex Bennée


      reply	other threads:[~2020-04-01  8:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAOragkw8XgbEOiaE9n=wKzPAMkzdOcqA5VA5ihN80v-g7V8TRw@mail.gmail.com>
     [not found] ` <20200329111311.272958fe@luklap>
2020-03-30 15:15   ` Qemu TCG Plugins - how to access guest registers? Alex Bennée
2020-03-30 17:40     ` Benjamin
2020-03-30 19:37       ` Alex Bennée
2020-03-31  0:25         ` Benjamin
2020-04-01  8:00           ` Alex Bennée [this message]

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=871rp7fxf8.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=benjamin@thatjames.org \
    --cc=cota@braap.org \
    --cc=lukasstraub2@web.de \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-discuss@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).