Re: [Qemu-devel] An architectural question

[Mulyadi Santosa]

Hi...

> First of all I want to apologize for this mail and hope that I won't wast to 
> much of your valuable time hacking on Qemu ;-). My goal is to implement a 
> tracing system in Qemu, which would suspend the emulation at certain points 
> (determined by linear addresses), dump some information from the memory and 
> resume the execution.
>

Sounds like you are in the same path like Argos
(http://www.few.vu.nl/argos/). Have you give it a check?

> My first attempt was to "hijack" the breakpoint system, by doing the 
> following: I've placed a breakpoint at the address of the instruction I 
> wanted to trace and inside of the main_loop function when the EXCP_DEBUG 
> exception occurred I performed the logging after which I called vm_start to 
> resume the operation. However the performance was abyssal...
>

yeah, I can imagine that... :) even simply dumping generated host
opcode will make qemu run slower...

> My next idea would be to replace the opcode generated for the debug point 
> with a procedure call (which would, instead of stopping the emulation, 
> perform the logging and let the emulation go on its way). I've implemented a 
> prototype for this by placing the address of the callback procedure inside of 
> the CPUState structure (given that this structure is accessible to the code 
> fragments), however it segfaults.
>

How do you implement it? as qemu _op_xxx function? have you made it as helper?

> My questions would be:
> - What would be the most optimal way to implement this? (Something that would 
> allow the OS to run at a usable speed inside of the emulated machine...)

have you tested simply by hooking gdb into qemu's gdb monitor and
"watch" certain memory address (range)?

Regarding your kqemu related questions....I am still investigating the
source code since long time ago. I got impression that it is doing
somekind of paravirtualization where guest is given separate process
address space. Every memory access is trapped by kqemu that acts as
hypervisor (think of Xen) and kqemu build shadow page table so
subsequent access to the same address can be done faster by looking up
to this table.

So if you create hook there, i think the code must be put
in...ehm..how do I say it technically... "trampolin pages"? it's a
page that mapped on both address space (guest and qemu). Whenever the
hook is hit, you switch back to qemu's original address space and run
anything you need to do. Then switch back to guest address space and
continue the virtualized guest.

For complete understanding, read kqemu-tech.html included in kqemu
tarball. Perhaps you can understand it way better than me.

I'm still learning about qemu internals too...

regards,

Mulyadi.