[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Improve QEMU performance with LLVM codegen and other te
Re: [Qemu-devel] Improve QEMU performance with LLVM codegen and other techniques
Tue, 6 Dec 2011 14:37:24 +0800
> 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
> 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 . The IBTC should take
cross page boundary constraint into consideration as block linking does (at
least in QEMU current design) .
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. ;-)
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)