qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] reverse execution.


From: Brendan Dolan-Gavitt
Subject: Re: [Qemu-devel] [RFC] reverse execution.
Date: Sun, 19 May 2013 16:47:02 -0500

Argh, reply all is needed.

On May 19, 2013 4:45 PM, "Brendan Dolan-Gavitt" <address@hidden> wrote:

We had to do something similar for our (soon to be released) record and replay implementation. To ensure interrupts are delivered at precisely the right time we added a global 64 bit instruction counter and then modified translate.c for each architecture to emit tcg ops that increment it before each instruction. At the end of translating a TB we store the number of instructions in that TB.

Then during replay, before every basic block executes (we disabled chaining) we check whether the current instruction count plus the number of instructions in the next TB is greater than the instruction count recorded for the next interrupt. If so, we retranslate and terminate the block at the right point so we can deliver the interrupt.

There is one gotcha to this,  which is that care had to be taken to not interfere with the search_pc mechanism.

If the above explanation isn't clear feel free to ask questions or just wait 2 weeks and read the code. I'm not sure how much work it would be to integrate what we have into the gdb stub but I'd be delighted if someone took on the task.

Cheers,
Brendan

On 19 May 2013 21:09, Mark Burton <address@hidden> wrote:
>         Note - what I understand by a basic block is something that ends in a
> jump/branch of some description. Hence, one thing I think you can say about a
> basic block is that each PC value within it is unique. Hence, if I know the
> number of basic blocks executed, and the current PC, then I should be able to
> re-run to there (assuming a deterministic system of course).

Assuming your rerun is strictly deterministic so you always exit
the basic block the same way each time, then yes, this amounts
to optimising the "instruction count" by doing it as "X basic
blocks then Y instructions". You could actually have this
really do the instruction count for you, if you track insns
per block at translation time. (There is some fiddling necessary
when we take an unexpected exception in the middle of a block
due to a load/store fault.)

> I'd be interested to know (a) if there is a sensible place for
> adding a basic block counter, and (b) if people like this route
> better or worse than an instruction counter?

I think you're probably best off getting the instruction counter
working properly before trying to optimise it...

thanks
-- PMM


reply via email to

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