Re: [Qemu-devel] Storing code caching

[John R. Hogerhuis]

On Thu, 2004-07-08 at 10:57, Martin Williams wrote:

> My idea is to write a program that caches individual files code (rather 
> than everything) - based around the idea that when a block is started 
> executing, the cache would be accessed and address minus the base 
> address (in other words the offset of the block) would be used to find 
> it within the cache (some algorithm is needed for an efficient method 
> of storing and locating these blocks as they will not be the same size 
> as the originals). The basic idea would then be that once qemu detects 
> a self modifying piece of code, (by a write to a memory address), it 
> would then black list the block in which the write happened (is this 
> possible?).
> 

Again... are you talking about User Mode QEMU where you are only running
one program + libraries or are you talking about QEMU running an
operating system?

I can imagine in running an OS you are going to get a lot of collisions
where two blocks are at the same offset. Throw in the length of the
block and I suppose you will have a lot less but I would guess it will
still happen enough to be a problem. You'll have to try and see. The
difference between the regular QEMU cache and one saved to disk is that
the segment selectors are not valid across runs.

In any event, if you do get a collision you can do a memcmp to see if
they are really the same exact thing. The trick is to have good enough
heurisitics that you don't do the memcmp very often.

> The program I would write would basically use the qemu core to process 
> an entire executable, creating the blocks that are executable on the 
> host machine, and store them. Then start work on modifying qemu to 
> recognise the existense of the cache file and use the blocks. Then deal 
> with the self-modyfing code issue as above ...
> 

QEMU loads the binary to RAM and builds the cache as it simulates its
execution. Working from a executable file without simulating is a bit
different. For that you should probably look into how a disassembler
works and also realize you have a lot of reworking to do if you want to
take the approach. I wouldn't, unless your goal is to be able to
actually make a new shippable translated binary image. If you are
looking to do that, I think that's, well... ambitious would be the nice
word.

> Martin
> 
> PS - I'm a CS undergrad, but I'm game for it anyway :)

Well that just means you can attack the halting problem with more
optimism than some of the other folks here ;-)  Actually when people
bring that up you just need to keep in mind that it is theory.
Important, but in engineering the solution just has to meet the
threshold of "good enough."