Is it legal to execute SVC from EL1 in ARMv8?
I have two cores in the same A53, and both are configured the same way with respect to system registers and MMU. When executing SVC #1 from EL1(S), one of the cores correctly generates syndrome 0x56000001 in ESR_EL1 (EC 0b01010101: "SVC instruction execution in AArch64 state"), but the other core generates syndrome 0x02000000 (EC 0b000000: "reason unknown").
If both cores are configured 100% exact the same, they should act the same. So conclusion is, it is not 100%!
You might need to check whether HFGITR_EL2_SVC_EL1 and SCR_EL3.FGTEn setting is the same.
"Is it legal to execute SVC from EL1 in ARMv8?"
Yes, it is legal.
Thank you for the suggestion, but it appears to me that HFGITR_EL2 is only available with FEAT_FGT, which my processor does not support.
I cannot disagree with your conclusion, but both cores are initialized by the same code, though they run in different address spaces.
When I compare the complete set of system registers, the only relevant differences seem to be in SP_ELx, ELR_ELx, TTBR0_ELx, and VBAR_ELx, and that because of the different address spaces.
Perhaps there is some unintended difference, but I'm having a hard time finding anything that looks wrong.
Thank you for the response. And is there any likely explanation for the difference in behavior that I'm seeing between the cores? (i.e. Expected and correct exception syndrome on one core, but different generic syndrome on the other?)
user56000001 said:I cannot disagree with your conclusion, but both cores are initialized by the same code, though they run in different address spaces.
Did you try swap addresses between cores?
Because of your question, I did try swapping addresses, but did not find it to make a difference.
But I do see that in D1.12.4 ("Synchronous exception prioritization for exceptions taken to AArch64 state") of the Armv8-A architecture reference manual, various interrupt types have different priorities. That makes me suspect that something is causing a higher priority exception than my SVC, on every single instruction, and consequently obscuring the ESR_EL1 syndrome.
At present I'm looking disfavorably on the debugger, because I can clear out ESR_EL1, but as soon as I do any stepping, ESR_EL1 immediately goes back to 0x02000000, even though no exception is taken as far as I can tell. I don't know enough about the debugger to know whether that is plausible.
Is there any documentation you can point me at to substantiate the statement? If so, I'll consider the question answered.
To confirm whether the SVC instruction causes the exception EC 0b000000: "reason unknown", did you perform step by step debugging?
It does support SVC at EL1, see the pseudo code in arm arm
aarch64/exceptions/syscalls/AArch64.CallSupervisor// AArch64.CallSupervisor()// ========================// Calls the SupervisorAArch64.CallSupervisor(bits(16) immediate)if UsingAArch32() then AArch32.ITAdvance();SSAdvance();route_to_el2 = PSTATE.EL == EL0 && EL2Enabled() && HCR_EL2.TGE == '1';bits(64) preferred_exception_return = NextInstrAddr();vect_offset = 0x0;exception = ExceptionSyndrome(Exception_SupervisorCall);exception.syndrome<15:0> = immediate;if UInt(PSTATE.EL) > UInt(EL1) thenAArch64.TakeException(PSTATE.EL, exception, preferred_exception_return, vect_offset);elsif route_to_el2 thenAArch64.TakeException(EL2, exception, preferred_exception_return, vect_offset);elseAArch64.TakeException(EL1, exception, preferred_exception_return, vect_offset);
SVC is not supported at EL2, EL3.
Yes, I did single step through the code. As soon as I execute the SVC instruction, I find myself at the current level sync SPx exception vector, and the ESR is 0x02000000. As I explained to 42Bastian Schick, I suspect that the 0x02000000 is the syndrome of some higher priority exception, and I suspect that my debugger is to blame.
Thank you for referencing the pseudocode. I'll mark this as an answer. But in response to your comment that "SVC is not supported at EL2, EL3," the pseudocode makes it fairly clear that the exception would be taken at the current PSTATE.EL. It couldn't be processed at EL1, but it would be available for higher-level processing if that was desirable.
"SVC is not supported at EL2, EL3" really means that SVC would not be used as system call function.
>I suspect that the 0x02000000 is the syndrome of some higher priority exception, and I suspect that my debugger is to blame
You could verify it by not using debugger and print out the ESR in the handler, to check whether the debugger should be blamed.
View all questions in Cortex-A / A-Profile forum