Re: reasoning beehind prohibiting VFP/NEON on AArch32

[Michael Zimmermann <sigmaepsilon92@gmail.com>]

I looked at ARMs TimerDxe and saw that mTimerNotifyFunction is called with
TPL_HIGH_LEVEL but didn't realize that RestoreTPL would call all pending
events.

Thank you for your help.
On Sun, May 13, 2018 at 1:39 PM Ard Biesheuvel <ard.biesheuvel@linaro.org>
wrote:

> On 13 May 2018 at 12:58, Michael Zimmermann <sigmaepsilon92@gmail.com>
wrote:
> >> 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?

> Event handlers are called from the timer interrupt handler. So unless
> you want to restrict use of the NEON to non-event handler context
> (which is not generally possible for libraries), you will need to
> raise the TPL to avoid any interruptions.

> > 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.

> I don't follow. Your NEON code running at TPL_APPLICATION may be
> interrupted at any time by event handlers running at higher TPL
> levels. If such code uses the NEON, it will corrupt your register
> file.



> > 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.