> > 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? > None that I would be aware of.
Ok. > > 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? > The exception is taken from the NEW vector table. Interesting! > > > 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. > Did that. Regardless of ArmInstructionSycnhronizationBarrier() and subsequent > enabling of the async abort > SError happens right in the ArmWriteVBar. Ok. Two theories: * When we take an exception, SError is masked. So perhaps we take another exception immediately after writing to VBAR_EL2, and that exception handler triggers the SError. I imagine that must be an asynchronous exception (i.e. one we can mask with DAIF). We should be able to see if that's the case if we change the ArmWriteVbar logic for EL2 to something like: mrs x1, daif msr daifset, #(0xb << 6) // D_IF masked mrs vbar_el2, x0 isb nop mrs daif, x1 nop If that is the case, I'd expect to take the SError immediately after the write back to daif. Ard, do we ever expect to take (non-fatal) synchronous exceptions? * As Ard originally suggested, the VBAR_EL2 address is close to some memory region we shouldn't speculatively fetch from, but for some reason do. Can you take a look at the new VBAR_EL2 value and your memory map, and see if it's close to anything that shouldn't be fetched from? Thanks, Mark. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
