On Fri, Jul 01, 2016 at 01:21:36PM +0200, Ard Biesheuvel wrote:
> On 1 July 2016 at 13:03, Leif Lindholm <[email protected]> wrote:
> > 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.
> >
>
> Well, the point is that we send debug output only to the serial port,
> and you can reasonably expect someone running a DEBUG build to be
> monitoring its output. On a RELEASE build, it makes more sense for the
> OS to handle it (although panicking as early as arm64 linux does is
> not very helpful either) since it will hang without any feedback to
> the UEFI console (even the RELEASE code in the default exception
> handler writes to the serial port directly rather than to UEFI's
> console)
No, I follow that logic completely.
I agree it is a lot less useful without the debug output.
However, I am asking if it is still not providing more information to
the user if the firmware hangs when an untraceable exception happens
during boot, than if the operating system hangs at a specific point
regardless where the SError was triggered.
If we say "other operating systems may handle this better, or at least
be able to successfully boot", then that is a decent argument to only
ASSERT on DEBUG.
/
Leif
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
