Hey,
I just remembered...the emulate branch has the correct version of
getregs/setregs. I updated QEMU in the git repo but didn't push the
changes to remote. So if you merged my branch into yours and are
using an old QEMU binary, you might get weird results. I will push
the QEMU changes tonight.
Brian
Quoting Andreas Nilsson <apn2107 at columbia.edu>:
> ok cool,
>
> we'll continue to look into it during the week.
>
> Brian Smith wrote:
>> 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
>>>
>>>
>>
>
> _______________________________________________
> Android-virt mailing list
> Android-virt at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/android-virt
>
>
