On Fri, Jul 01, 2016 at 12:53:13PM +0200, Ard Biesheuvel wrote: > SErrors (formerly called asynchronous aborts) are a distinct class of > exceptions that are not closely tied to the currently executing > instruction. Since execution may be able to proceed in such a condition, > this class of exception is masked by default, and software needs to unmask > it explicitly if it is prepared to handle such exceptions. > > On DEBUG builds, we are well equipped to report the CPU context to the user > and it makes sense to report an SError as soon as it occurs rather than to > wait for the OS to take it when it unmasks them, especially since the current > arm64/Linux implementation simply panics in that case. So unmask them when > ArmCpuDxe loads.
So, I agree with this patch: Reviewed-by: Leif Lindholm <[email protected]> But if we're doing this, I wonder if we should not also do so for non-DEBUG builds? Do we expect other operating systems to do anything useful with the exception? If not, hanging when the error occurs sounds more informative than hanging as soon as you start your OS. > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel <[email protected]> > --- > ArmPkg/Drivers/CpuDxe/Exception.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/ArmPkg/Drivers/CpuDxe/Exception.c > b/ArmPkg/Drivers/CpuDxe/Exception.c > index c3107cd4a6bc..d806a5fdf910 100644 > --- a/ArmPkg/Drivers/CpuDxe/Exception.c > +++ b/ArmPkg/Drivers/CpuDxe/Exception.c > @@ -62,6 +62,15 @@ InitializeExceptions ( > Status = Cpu->EnableInterrupt (Cpu); > } > > + // > + // On a DEBUG build, unmask SErrors so they are delivered right away rather > + // than when the OS unmasks them. This gives us a better chance of figuring > + // out the cause. > + // > + DEBUG_CODE ( > + ArmEnableAsynchronousAbort (); > + ); > + > return Status; > } > > -- > 2.7.4 > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
