On Mon, Nov 16, 2015 at 06:23:20PM +0000, Vladimir Olovyannikov wrote: > > -----Original Message----- > > From: Mark Rutland [mailto:mark.rutl...@arm.com]
[...] > > What is the earliest point in EDK2 that you have unmasked SError? > > > > Are you doing this in PrePeiCoreEntryPoint.S, or later? > Thanks for the pointers Mark. > > Async abort occurs in ArmWriteVBar() called by InitializeDebugAgent(), > DebugAgentSymbolsBaseLib.c. Interesting. Is the SError taken directly to EL2? I understood from your previous reply that the EDK2 exception handler was invoked at this point, so is there anything at EL3 which is trying to catch exceptions and then re-inject them down to EL2? The fact that we're clearly able to take the SError via the table confuses me; it makes it sound like the table is fine. Is that exception taken via the old vector table, or the new one we're trying to install with this write to VBAR_EL2? > Prior to this call I can easily enable async aborts with no "bad" > consequences. > > Here is the exact instruction causing the SError in the ArmWriteVBar(): > 2: msr vbar_el2, x0 // Set the Address of the EL2 Vector Table > in the VBAR register As SError is asynchronous, it's not necessarily the case that the write to VBAR_EL2 is the trigger. I note that in ArmPkg/Library/ArmLib/AArch64/AArch64Support.S, there is an ISB at the end of ArmWriteVBar(). That might happen to "flush" a pending SError on the CPU and cause it to be taken. > Could it mean that I do not have enough privileges in the UEFI for this > operation? There are no traps or enables affecting VBAR_EL2. So long as EDK2 is running at EL2 or higher it should be sufficiently privileged to read or write VBAR_EL2. > What would you advise? My hunch is that we have a pending SError that gets "flushed" by an ISB. You should be able to add ArmInstructionSynchronizationBarrier() calls in the general vicinity of InitializeDebugAgent() (e.g. before the call to ArmWriteVBar(), in the caller of InitializeDebugAgent(), before it and the previous few functions are called). That may cause the SError to be taken closer to its trigger, and if so it would be possible to bisect down to the trigger. Thanks, Mark. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
