Query regarding extracting instruction which caused a data-abort exception

[rijurekha at ...71...]

We read the dfsr value with changes in
base-hw/include/spec/imx53/vm_state.h,
base-hw/src/core/spec/arm_v7/trustzone/kernel/vm.cc, and
os/src/server/tz_vmm/include/vm_base.h dump() function.

We got dfsr = 00001008, which gives b101000 for the status bits, matching
"bx01000 precise external abort, nontranslation" with "x=1=AXI Slave error
caused the abort" (according to
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Bgbiaghh.html).

Got dfar = 53fbc080 physical address, which is in the UART range, and we
have made UART secure in csu_config.h, so makes sense that we get an AXI
slave error.

Basic questions:
(1) In base-hw/src/core/include/spec/arm/cpu_support.h, we see Cpu structs
Dfsr and Dfar and the read functions, which read from the cp15 registers.
This is what we explicitly read on a data abort and assign to _state
variables. How do the other _state variables r0-r12, ip, lr, etc. defined
in base/include/spec/arm/cpu/cpu_state.h get populated? In
os/src/server/tz_vmm/include/vm_base.h, constructor has this
initialization for _state:

_state((Genode::Vm_state*)Genode::env()->rm_session()->attach(_vm_con.cpu_state()))

What does this do? When we read or write from _state->ip or _state->r5,
are we accessing an actual register or a memory location? Where does the
memory read/write get translated to an actual register read/write? Like
dfar and dfsr, do we need explicit assignment of the other _state
variables in the data abort handler, so that in dump() function we get the
correct _state->ip?

(2) For precise data aborts,
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344f/Beiibjca.html
says the following.

After dealing with the cause of the abort, the handler executes the
following return instruction, irrespective of the processor operating
state at the point of entry:
SUBS PC,R14_abt,#8
This restores both the PC and the CPSR, and retries the aborted instruction.

But as we discussed above in this thread, we need to see _state->ip and
not _state->abt.lr, because this is an external abort on the AXI bus, and
not an mmu based internal abort. Is this behavior (lr_abt not updated and
ip needs to be read) something genode specific, or ARM specific? We see
cpsr=0x93, which makes EA=0. So external aborts are not programmed to trap
to monitor mode. So what is the flow when an imprecise external abort
occurs in the normal world? Does it go to the normal world exception
handler or comes to genode exception handler? What code can I look at to
understand this flow?