Taking exceptions from EL1 to EL1: Problems with SVC

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

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 Supervisor
AArch64.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) then
AArch64.TakeException(PSTATE.EL, exception, preferred_exception_return, vect_offset);
elsif route_to_el2 then
AArch64.TakeException(EL2, exception, preferred_exception_return, vect_offset);
else
AArch64.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.