Hi Max, > If your code is available online I can try it myself, the question is > where is it hosted then. > If not, then link to kernel binary and qemu exec trace would help me to start.
Personally, I really want to make our work public, but I am not the decision maker. I'll push it toward open source however. > >> > ?..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 > >> > > >> > which turns out should be function check_timer > >> > (arch/i386/kernel/io_apic.c). I > >> > >> If it hangs inside QEMU itself then you may try to backport commit > >> 4f61927a41a098d06e642ffdea5fc285dc3a0e6b that fixes > >> infinite loop caused by hpet interrupt probing. > > > > 狢 don't understand. What "it hangs inside QEMU itself" supposed to mean? > > QEMU doesn't execute guest code doing something for itself vs. QEMU > executes guest code in loop checking for something that doesn't > happen. > > I'm talking about the first case. They may be distinguished from e.g. > guest debugger connected to QEMU's gdbstub -- in the former case it > cannot break guest execution by ^C. It turns out this is our IBTC optimization problem [1]. The IBTC should take cross page boundary constraint into consideration as block linking does (at least in QEMU current design) [2]. As I said before, we have two code caches in our framework: one for basic block, the other for trace. I forgot to turn off trace's IBTC optimization as it doesn't consider cross page boundary right now. As a workaround, we return to QEMU (dispatcher) while doing IBTC lookup, and the problem I mentioned disappeared. Sometimes I feel I am chaseing a ghost when debug our system. ;-) [1] http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg01424.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2011-08/msg02249.html Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj
