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

[Julien Grall <julien@xxxxxxx>]

Hi,

I will combine my answers for this thread in one single e-mail.

On 17/11/2021 16:35, Bertrand Marquis wrote:
> > On 17 Nov 2021, at 16:21, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxxxxx> 
> > wrote:
> >
> > Hi Bertrand,
> >
> > Many thanks for your response.
> >
> > On 17/11/2021 15:48, Bertrand Marquis wrote:
> > > Hi Ayan,
> > > > On 16 Nov 2021, at 16:24, Ayan Kumar Halder <ayan.kumar.halder@xxxxxxxxxx> 
> > > > wrote:
> > > >
> > > > Hi Bertrand,
> > > >
> > > > Thanks for looking into it.
> > > >
> > > > On 16/11/2021 15:36, Bertrand Marquis wrote:
> > > > > 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.
> > > > That is surprising. The reason being if I try to read the GICC register 
> > > > (0x3002000) with post indexing then it works fine.
> > > When the ISV bit is not set, Xen would have to decode the instruction to actually emulate the 
> > > access and properly modify the registers values as long as providing the 
> > > “emulated” access value.
> > This is very interesting. Is this being done for any of the other instructions 
> > in Xen ?
> No Xen is not trying to decode any instructions.
We actually decode some instructions (see arch/arm/decode.c). This was 
necessary because early revision of Cortex-A15 would not properly fill 
syndrome for Thumb instructions.
decode_instruction() could be extended to handle the specific 
instruction if needed.
> If you look at Linux source code, this is the kind of stuff that the kernel is 
> delegating to user application (qemu) to do as it can be quite complex.
>
> > > There is not such a decoder in Xen right now which means those kind of accesses 
> > > are not supported for emulated mmio accesses.
> > I am actually trying to understand where I will need to make the changes if I 
> > have to add support for the decoder. The reason being this issue is being faced 
> > by one of our customer application.
> > Besides changing the instruction to prevent post increment, is there any other 
> > mitigation ?
> Not that I know of.
Decoding the instruction is the only solution if you don't want to 
update the baremetal app.
> > The reason being I don't see a way to instruct the compiler to not generate the 
> > post indexing instructions.
In general, it is not safe to let the compiler decide for you how to 
access the MMIO registers as it can do all sort of optimization behind 
your back. That's why...
> You can define io access functions instead of letting the compiler generate the 
> read/write functions.
> Look at arch/arm64/include/asm-arm/io.h in linux for example.
... Linux provides io{read, write} helpers.

@Ayan, is the code written in assembly or C? If the latter, how is it 
written?
That said, the ldr writeback instructions should be safe to use. It 
happens that we never had OS using them before.
Cheers,

--
Julien Grall