Re: can't acknowledge non-secure group 1 interrupt during EL3 execution

[Peter Maydell]

On Thu, 6 May 2021 at 04:02, <ckim@etri.re.kr> wrote:
>
> Hello, all
>
> I need help here from an expert..(Peter Meydell as usual? )
>
> In baremetal program (in EL3, secure), I can acknowledge an interrupt grouped 
> in non-secure group 1.

Note that the manual (section 4.6 "Interrupt grouping") states that
"Arm expects [NS Group 1] interrupts to be handled at Non-secure EL2
in systems using virtualization, or at Non-secure EL1 in systems not
using virtualization." So if you're trying to handle them at EL3 then
you're doing something nonstandard, and you should consider whether
you have the right system design.

> But the manual(gic arch spec. version G. p.51) says, the priority drop for a 
> non-secure interrupt (by writing to ICC_EOIR1_EL1) is done only when the PE 
> is in non-secure state, while in my case the PE is in secure state.
>
>
>
> But in the description of ICC_CTLR_EL3.RM, when it’s set to 0, (my case), it 
> reads
>
> Secure Group 0 and Non-secure Group 1 interrupts can be acknowledged and 
> observed
>
> as the highest priority interrupt at the Secure Exception level where the 
> interrupt is
>
> taken
>
> So it was acknowledged as the manual, but shouldn’t it be also 
> priority-downable? (the manual isn’t clear about this).

The pseudocode for ICC_EOIR1_EL1 is clearer: either the EOIR write should
be ignored (wrong group, bad interrupt number, etc), or it should have
the correct effect (both dropping priority and also deactivating depending
on the EOI mode).

I think there is a QEMU bug here -- we assume that the combination of
"which register" and "is the CPU secure" is enough to identify a single
valid interrupt group, and don't account for "in EL3 it could be either
G1NS or G1".

Do you have a test case I can reproduce this with ?

> I tried grab for ‘ICC_CTLR_EL3_RM’ but it’s only defined and not being used 
> anywhere.
>
> Can we say that this ICC_CTLR_EL3_RM is not yet modeled in qemu-5.1.0? 
> (because in rtl simulation my colleague is doing, it’s being processed ok 
> including the priority drop).

ICC_CTLR_EL3.RM is part of the "legacy model" of GIC operation (as described
in section 14.1 of the GICv3 spec, and including a memory-mapped register
interface rather than system registers). QEMU does not and has no
plans to implement
legacy operation, so for us ICC_SRE_EL1.SRE is RAO/WI and
ICC_CTLR_EL3.RM is RAZ/WI.
If your guest is trying to set RM to 1 then this won't work on QEMU; if it is
not trying to set it to 1 then it should be OK.

thanks
-- PMM