From: "Byron Hawkins" <byronh@uci.edu>
To: 'Peter Maydell' <peter.maydell@linaro.org>
Cc: 'QEMU Developer List' <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Running programs that dynamically generate code
Date: Tue, 2 Sep 2014 01:16:57 -0700 [thread overview]
Message-ID: <40d301cfc686$453237b0$cf96a710$@uci.edu> (raw)
In-Reply-To: <CAFEAcA8VOG1j7nQT-Ct=7W8sy_xYgd2dv-4a3JgA-JHxWp=EOQ@mail.gmail.com>
> -----Original Message-----
> From: Peter Maydell [mailto:peter.maydell@linaro.org]
> Sent: Friday, August 29, 2014 2:23 AM
> To: Byron Hawkins
> Cc: QEMU Developer List
> Subject: Re: [Qemu-devel] Running programs that dynamically generate
> code
>
> On 29 August 2014 03:24, Byron Hawkins <byronh@uci.edu> wrote:
> > Hi, I’m working on a research project to optimize binary translation
> > for target applications that dynamically generate code, such as
> > browser JIT engines. When I run the octane benchmark in Chrome v8
> > under QEMU (i.e., qemu-x86_64), it shows significant overhead compared
> > to a native run. Can someone tell me how QEMU maintains consistency
> > with the target application when it dynamically generates code?
>
> When we generate code from a particular page of guest RAM, we arrange to
> trap into QEMU if/when the guest writes to that page (either using QEMU's
> own softmmu facilities if using the -system- emulators, or by marking the
> page readonly and handling the segfault if using the linux-user emulators). If
> we trap then we flush the cached translation we had for that page and let
> the guest write proceed.
> For guest CPUs like x86 there is some further complication to allow writes to
> the page the guest is currently executing from to behave as the guest
> expects. For guest CPUs like ARM where the architecture requires guest
> code to perform icache/dcache maintenance operations before the writes
> are visible to instruction fetch, we take advantage of that to avoid jumping
> through some of the hoops.
>
> The most obvious cause of overhead compared to a native run would be that
> we emulate all our floating point and SIMD operations, so unless Chrome's
> JIT is sticking strictly to integer operations we're bound to go rather slower.
>
> -- PMM
Thanks Peter. Can you tell me how much translated code is flushed when a write is detected in an executable region? Is it just the code translated from the one modified page?
next prev parent reply other threads:[~2014-09-02 8:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-29 2:24 [Qemu-devel] Running programs that dynamically generate code Byron Hawkins
2014-08-29 9:22 ` Peter Maydell
2014-09-02 8:16 ` Byron Hawkins [this message]
2014-09-02 8:50 ` 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='40d301cfc686$453237b0$cf96a710$@uci.edu' \
--to=byronh@uci.edu \
--cc=peter.maydell@linaro.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.