Re: reasoning beehind prohibiting VFP/NEON on AArch32

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

> No, the other way around. You should raise the TPL to TPL_HIGH_LEVEL
> to prevent being interrupted by something that may corrupt the NEON
> registers.
But isn't that only necessary if you assume that interrupt-handlers use VFP
registers?
afaik on ARM <TPL_HIGH_LEVEL events are never called from the timer
interrupt handler so basically if you're going to be interrupted during VFP
operations no other <TPL_HIGH_LEVEL code should ever run.

Please correct me if I'm misunderstanding something.
On Sun, May 13, 2018 at 12:16 PM Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:

> On 13 May 2018 at 11:48, Michael Zimmermann <sigmaepsilon92@gmail.com>
wrote:
> > So basically using them should be safe as long as you're in
> > EfiGetCurrentTpl() < TPL_HIGH_LEVEL, right?

> No, the other way around. You should raise the TPL to TPL_HIGH_LEVEL
> to prevent being interrupted by something that may corrupt the NEON
> registers.

> > Also, it'd probably be trivial to add  VFP/NEON regs to
> > EFI_SYSTEM_CONTEXT_ARM though that wouldn't help when writing apps for
> > existing uefi platforms.

> EFI_SYSTEM_CONTEXT_ARM is covered by the UEFI spec, so that is not
> going to change.

> > On Sun, May 13, 2018 at 9:32 AM Ard Biesheuvel <
ard.biesheuvel@linaro.org>
> > wrote:
> >
> >> On 12 May 2018 at 23:11, Michael Zimmermann <sigmaepsilon92@gmail.com>
> > wrote:
> >> > For AArch32 the spec says in 2.3.5.3:
> >> >> Floating point, SIMD, vector operations and other instruction set
> >> > extensions must not
> >> > be used.
> >> >
> >> > For AArch64 the spec says in 2.3.6.4:
> >> >> Floating point and SIMD instructions may be used.
> >> >
> >> > So is there a reason why AArch32 is not allowed to use Floating point
> >> > operations?
> >> > I'd understand if this restriction was limited to runtime services
only
> > but
> >> > I don't see how it makes sense for boot services.
> >> >
> >> > I've written a patch which adds NEON support to FrameBufferBltLib to
> >> > increase the rendering performance(by a lot actually) for 24bit
displays
> >> > and thought about sending it to the mailing list - that's why the
> > question
> >> > came up.
> >> >
> >
> >> The reason for the difference between AArch64 and the other EFI
> >> architectures is that AArch64 does not have a softfloat ABI, so it is
> >> impossible to compile floating point code [portably] without enabling
> >> VFP/NEON. This is why AArch64 is the exception here.
> >
> >> Currently, the AArch32 CPU context structure [EFI_SYSTEM_CONTEXT_ARM]
> >> does not cover VFP/NEON registers, and so they are not
> >> preserved/restored when an interrupt is taken. This means you cannot
> >> use VFP/NEON registers in an event handler or you will corrupt the
> >> VFP/NEON state of the interrupted context.