Re: Xen/ARM - Query about a data abort seen while reading GICD registers

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Ayan,

> On 16 Nov 2021, at 15:27, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxxxxx> 
> wrote:
> 
> Hi Xen/Arm experts,
> 
> I am facing a very strange issue while running a baremetal application as a 
> DomU guest on arm64 platform.
> 
> The baremetal app tries to read the GICD register with post indexing as 
> follows :-
> ldr x1, =0x3001000
> ldr w2, [x1], #4 <<<------ PC = 0x40000ca8

Increment on on load is not supported by the emulation layer.

Could you try with:
add x1, x1, #4
ldr w2, [x1]

Regards
Bertrand

> 
> And then I get :-
> HSR=0x92000005 pc=0x00000040000ca8 gva=0x3001000 gpa=0x00000003001000
> 
> This problem occurs only while reading the GICD registers with post indexing. 
> If I read the register with pre-indexing, then I do not see any abort. 
> Alternatively, if I read GICC register with post indexing, I don't see the 
> abort either.
> 
> From the HSR value, I interpret it as
> EC = 100100b # Data abort from lower exception
> IL = 1b # 32 bit instruction trapped
> DFSC = 101 # Translation fault level 1
> 
> On debugging, I found that the abort is triggered from
> 
> try_handle_mmio()
> { ...
>    /* All the instructions used on emulated MMIO region should be valid */
>    if ( !dabt.valid ) {
> 
>        return IO_ABORT;
>    }
> ...
> }
> 
> From the Arm V8 Arm specs, I understand that dabt.valid is ISV, bit[24] in 
> "ISS encoding for an exception from a Data Abort".
> 
> 
> I saw that the caller is
> 
> do_trap_guest_sync() "case HSR_EC_DATA_ABORT_LOWER_EL"
> where dabt.valid is false.
> In the success scenario, dabt.valid is true.
> 
> I could not find the caller for do_trap_guest_sync()
> 
> So, can anyone help me here
> 1. Who is the caller for do_trap_guest_sync() ?
> 2. Any idea on what the issue is and how I can debug it further ?
> 
> Kind regards,
> Ayan
>