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.