Hi, Peter Meydell,
Thanks for the information. I was almost aware of the facts you mentioned(NS group 1 is supposed to be processed at EL1), but I thought EL3 can still process NS group 1 exception. Correct me if I’m wrong. I can still process the interrupt using group 0. It’s because there’s discrepancy between RTL and qemu emulation.
(In gicv3 software overview release B, 3.4 Security model, table 6)
I later found the interrupt is acknowledged first time (I can see the active state is turned off after returning to main,
Maybe because it was my mistake in build during the test), but the second interrupt never happens.
I'll need some time to look into this myself first.
And something went wrong while upgrading my ubuntu 16.04 machine to 18.04 just now and can't boot the machine now.
I could give you a test case if I still think qemu is strange later.(I think the bug should be in my side)
Thank you and best regards,
Chan Kim
> -----Original Message-----
> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Thursday, May 6, 2021 5:09 PM
> To: Chan Kim <ckim@etri.re.kr>
> Cc: qemu-discuss <qemu-discuss@nongnu.org>
> Subject: Re: can't acknowledge non-secure group 1 interrupt during EL3
> execution
>
> 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