Re: [Qemu-devel] minimal linux distribution for qemu

[Rob Landley <rob@landley.net>]

On 08/18/2013 08:57:08 AM, Herbei Dacian wrote:
> 
> good to know.
> I was working back in 2005-2006 with a company that had a 4MB kernel.
> At that time I was too inexperienced to work at that level but I  
> thought now I could reproduce their work with some help.
> Anyhow for the moment I'll go for 256 MB of ram board just so that I  
> don't worry too much about things that are not yet relevant for me.
> But thanks again for the warning.
> But since you helped me soo much I have another question.
> Is it fisible to change the emulator so that I may visualize the  
> following aspects:
> _ address of the currently executed instruction from the guest system
> _ if this instruction is a form of jump like call return conditional  
> jump.
> _ the address or range of addresses read by this instruction
> _ the address or range of addresses written by this instruction

If you feed qemu the -s option it'll open a network port you can  
connect to to provide the gdbserver protocol (gdb's "target remote"  
command attaches to this). For system emulation it acts like a jtag  
attached to the emulated hardware, letting you see registers and such.

> I read some things about the emulator and if I understood it  
> correctly the emulator
> breaks the instructions of the gurest platform in micro ops which are  
> then executed
> on the host operation system.

Not really, no.

QEMU translates large blocks of code (used to be pages, now it's  
variable sized chunks depending on where the return instruction is) and  
keeps the translated versions cached (sort of like a java JIT). The  
main QEMU loop then calls the translated functions which execute until  
they return or get interrupted by signals (simulating things like timer  
IRQ). This is why QEMU is so fast, the actual translation overhead is  
amortized by the resulting native code being run lots of times, a  
function or loop gets translated once and then runs as native code.

This means that "the address of the currently executing instruction"  
isn't really something qemu naturally tracks, because although there  
_is_ a copy of the untranslated code page, it's not what we're running.  
The gdbserver code tries to do so artifically, but it's slow and  
awkward and not always perfect.

Self-modifying code is actually a horrible thing to do to qemu, from a  
performance perspective. Every time the emulated code page is modified,  
the cached copy of the translated code is discarded and the entire page  
gets retranslated. This means that in Aboriginal Linux, the shell  
scripts ./configure runs sped up 20% when I replaced my dynamically  
linked busybox with a statically linked one, due to the extra  
translations caused by the relocation fixups.

Rob