qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: ckim
Subject: RE: can't acknowledge non-secure group 1 interrupt during EL3 execution
Date: Tue, 4 May 2021 13:16:55 +0900

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,

Im 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 its 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 qemus gic model error?  (when its assigned in group 0 interrupt, it works ok, of course using corresponding registers)

Thanks!

Chan Kim

 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]