qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Running programs that dynamically generate code


From: Byron Hawkins
Subject: Re: [Qemu-devel] Running programs that dynamically generate code
Date: Tue, 2 Sep 2014 01:16:57 -0700


> -----Original Message-----
> From: Peter Maydell [mailto:address@hidden
> 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 <address@hidden> 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?




reply via email to

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