reasoning beehind prohibiting VFP/NEON on AArch32

reasoning beehind prohibiting VFP/NEON on AArch32

[Michael Zimmermann]

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.

Thanks
Michael

Re: reasoning beehind prohibiting VFP/NEON on AArch32

[Ard Biesheuvel]

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.

Re: reasoning beehind prohibiting VFP/NEON on AArch32

[Michael Zimmermann]

So basically using them should be safe as long as you're in
EfiGetCurrentTpl() < TPL_HIGH_LEVEL, right?
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.
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.

Re: reasoning beehind prohibiting VFP/NEON on AArch32

[Ard Biesheuvel]

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.

Re: reasoning beehind prohibiting VFP/NEON on AArch32

[Michael Zimmermann]

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

Re: reasoning beehind prohibiting VFP/NEON on AArch32

[Ard Biesheuvel]

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.

Re: reasoning beehind prohibiting VFP/NEON on AArch32

[Michael Zimmermann]

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.