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

[ckim]

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.

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).

I can see using gdb that current qemu code(5.1.0) prevents it from lowering the priority because the security state of the irq and PE is different

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).

Thanks!

Chan Kim

 

From: ckim@etri.re.kr <ckim@etri.re.kr>
Sent: Tuesday, May 4, 2021 1:17 PM
To: 'qemu-discuss' <qemu-discuss@nongnu.org>
Subject: RE: can't acknowledge non-secure group 1 interrupt during EL3 execution

 

Hi,

This morning I found the problem was that I actually read s3_0_c12_c8_0(ICC_IAR0_EL1) when I should read s3_0_c12_c12(ICC_IAR1_EL1) for non-secure group 1 interrupt.

(I though the #ifdef #else #endif in the .S file is processed into .s file but looks like the last statement is selected. I should have used gcc (not as) to preprocess the file. Sorry it was my bad)

So the acknowledge is done correct now. Now I’m trying to figure out why the second interrupt (by writing a command to the peripheral) is not causing the exception.

Chan Kim

 

From: ckim@etri.re.kr <ckim@etri.re.kr>
Sent: Monday, May 3, 2021 9:40 PM
To: 'qemu-discuss' <qemu-discuss@nongnu.org>
Subject: can't acknowledge non-secure group 1 interrupt during EL3 execution

 

Hello, list members,

I’m testing a simple bare-metal program, so the program runs at EL3.

I assigned an SPI (INTID=208) to non-secure group 1 and to acknowledge it I read s3_0_c12_c12_0 (ICC_IAR0_EL1) but it gives me INTID 1021.

I tried reading s3_0_c12_c12_0 (ICC_IAR1_EL1) but it’s the same.

The gic architectgure specification manual says,

 

1021 The GIC returns this value in response to a read of ICC_IAR0_EL1 or ICC_HPPIR0_EL1 at EL3,

to indicate that the interrupt being acknowledged is one which is expected to be handled at

Non-secure EL1 or EL2. This INTID is only returned when the PE is executing at EL3 using

AArch64 state, or when the PE is executing in AArch32 state in Monitor mode.

This value can also be returned by reads of ICC_IAR1_EL1or ICC_HPPIR1_EL1 at EL3 when

ICC_CTLR_EL3.RM == 1, see Asymmetric operation and the use of ICC_CTLR_EL3.RM on

page 14-862

 

About the ICC_CTLR_EL3.RM bit, the document says,

ICC_CTLR_EL3.RM controls whether software executing at EL3 can acknowledge or observe Secure Group 0 and

Non-secure Group 1 interrupts as the highest priority pending interrupt.

 

Because my interrupt is in group 1, I think I should read ICC_IAR1_EL1. And because the ICC_CTLR_EL3.RM == 0, I think the EL3 should be able to acknowledge this non-secure group 1 interrupt.

Can this be a qemu’s gic model error?  (when it’s assigned in group 0 interrupt, it works ok, of course using corresponding registers)

Thanks!

Chan Kim