Given the randomness, perhaps you're taking an interrupt (IRQ, dabt) while executing on the host and that is causing a problem? Except for software interrupts, our handlers should only get control when the exceptions occur while running in user mode. If we got control when running in svc mode I can see problems that you're describing, a situation where we treat an exception as if it occurred on the guest but it really happened on the host. You can verify we don't get control while the host is running by setting a trap on common_interrupt and setting a trap on guest_run. If common_interrupt hits more than once before guest_run, that means an interrupt occurred while the host was doing its processing and we got control for it. On entry to common_interrupt, register 5 will have the interrupt we took (defined in kvm_arm.h), which might be of use. I would try it myself, but I have been unable to reproduce the problem. Good luck! Brian Christoffer Dall wrote: > hmmm. I tried running it several times and I got the error described 4 > times, but it proceeded further two times. > > I will investigate further tomorrow. > > On Wed, Apr 29, 2009 at 8:02 PM, Brian Smith <bls2129 at columbia.edu > <mailto:bls2129 at columbia.edu>> wrote: > > Hi Christoffer, > I ran the provided guest zImage-2.6.17 and again got to 0x1008C, > so I can't say what's going on with any certainty. Some questions > that may make sense of things... > > 1) What is the real instruction at 0x00010040? For me, it is > 0x1a000001 (BNE PC+4). To figure out the real instruction, I trap > at kvmarm_handle_exit, and on entry: > > p/x vcpu->arch.guest_regs > this shows regs 0-15 followed by the "guestified" CPSR. Reg 15 > shows (for an SWI) the next instruction (in this case it should > show 0x00010044) > > For me, the emulation code takes the branch to 0x1004C, which I > trapped on (same method you did), the trap did hit for me. I > don't think this matters, but I set the trap while using the host > page table, not the shadow page table. > > 2) Did you recompile QEMU to pick up the new setregs? > > yes > > > 3) Are you running straight from the emulate branch? If not, did > you merge from commit ffb9d4df3c91936da03406eb8d7a4dcca3a14744? > > yes, merge from ffb9d... > > > > 4) What other traps do you have set in the debug below? getOp is > called twice for every SWI. First its called in > kvmarm_handle_exit to figure out if the instruction should be > emulated, then in kvmarm_emulate_trans_op when figuring out what > instruction to emulate. kvmarm_translate_getOp is a very simple > loop, I find it hard to believe you are stuck in there. Have you > stepped through the loop? Does it return to the caller? > > > it returns to the caller, but the times it worked to took several > seconds, which seems a bit weird. As I said, I will investigate more > tomorrow. > > > > If you want to discuss this, I'll be on skype for the rest of the > night > > > I'm exhausted now, so I will stop working, but maybe a quick chat > tomorrow night will prove useful. > > Take care. > > > > Hope this helps... > Brian > > Christoffer Dall wrote: > > Hi Brian. > > When we are running the guest boot code, we get as far as to > the instruction on 0x00010040. On this trap, it seems that the > translation code sits in an infinite loop. Would you mind > looking at it? > > We have built our own linux arm image to ease debugging and > disassembly. You can find the binary in the svn repo in > bin/zImage-2.6.17. Please use this when testing so we don't > have any inconsistencies. > > Attached here is the debug output: > > ---- > Breakpoint 1, 0x00010040 in ?? () > 694 { > (gdb) x 0x10040 > 0x10040: 0xef000000 > (gdb) b *0x10044 > Breakpoint 2 at 0x10044 > (gdb) b *0x1004c > Breakpoint 3 at 0x1004c > (gdb) b *0x10064 > Breakpoint 4 at 0x10064 > (gdb) cont > Continuing. > > Program received signal SIGINT, Interrupt. > kvmarm_translate_getOp (instr=<value optimized out>) at > arch/arm/kvm/arm_translate.c:70 > 70 for(i=0; i<NUM_TRANS_INSTR; i++) { > (gdb) c > Continuing. > > Program received signal SIGINT, Interrupt. > kvmarm_translate_getOp (instr=<value optimized out>) at > arch/arm/kvm/arm_translate.c:70 > 70 for(i=0; i<NUM_TRANS_INSTR; i++) { > (gdb) c > Continuing. > --- > > Best, > Christoffer > ------------------------------------------------------------------------ > > _______________________________________________ > Android-virt mailing list > Android-virt at lists.cs.columbia.edu > <mailto:Android-virt at lists.cs.columbia.edu> > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > > >
