Andreas, Thanks for the update. On your suggestion I merged kvmrun into emulate and got the emulation working with the shadow page tables. I too got to a point where the guest runs until the first dabt exception, mine occurs at 0x88 on a load instruction though, but the storage it's trying to load is the same as what you were showing (different guest kernel's?). I updated arm_insterrupts.S to save the fault address register in vcpu->arch.host_far so when it gets to kvmarm_handle_exit you have the address it was trying to access. I also added code in kvmarm_handle_exit that attempts to fix the access then reexecute the instruction. But when the instruction is reexecuted a dabt exception again occurs and we get in an infinite loop forever executing the instruction and causing a dabt exception. I ran out of time to investigate why what I did wasn't sufficient (search "make_pages_present" in arm.c). On the plus side it's the user program that is stuck in an infinite loop, the kernel is okay. Regards, Brian Andreas Nilsson wrote: > Brian, > > we debugged the boot process today and identified were we get the crash. > It's in a loop between offsets 0xa0 and 0xb8 in head.S. I've described > what happens in the wiki and also added pages about MMU emulation and > moved the boot info to a separate section. Everything should be > committed to the kvmrun branch. > > For the weekend I think there are two main tasks you can look at: > > 1. Before we crash we actually encounter some privileged instructions > which are currently handled as no-ops since we commented out the > translation/emulation code. It could make sense to try to get to the > same point where we are now but actually emulate the privileged > instructions on the way there. It won't solve our crash but it will be > good testing of the translation/emulation code for the future. > > There are actually a whole lot of branches taken which would test the > block identification and translation pretty well. > > 2. Copy the shadow page table code into the emulation branch and play > around with it to see if you can figure out how to resolve the crash. > > GL! > > /Andreas > _______________________________________________ > Android-virt mailing list > Android-virt at lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > >
