Re: [edk2] reasoning beehind prohibiting VFP/NEON on AArch32
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 wrote: > On 13 May 2018 at 12:58, Michael Zimmermann 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 > interrupt handler so basically if you're going to be interrupted during VFP > > operations no other > > > 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.biesheu...@linaro.org> > > wrote: > > > >> On 13 May 2018 at 11:48, Michael Zimmermann > > 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.biesheu...@linaro.org> > >> > wrote: > >> > > >> >> On 12 May 2018 at 23:11, Michael Zimmermann < sigmaepsilo...@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. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] reasoning beehind prohibiting VFP/NEON on AArch32
On 13 May 2018 at 12:58, Michael Zimmermann 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 interrupt handler so basically if you're going to be interrupted during VFP > operations no other > 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 > wrote: > >> On 13 May 2018 at 11:48, Michael Zimmermann > 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.biesheu...@linaro.org> >> > wrote: >> > >> >> On 12 May 2018 at 23:11, Michael Zimmermann >> > 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. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] reasoning beehind prohibiting VFP/NEON on AArch32
> 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 wrote: > On 13 May 2018 at 11:48, Michael Zimmermann 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.biesheu...@linaro.org> > > wrote: > > > >> On 12 May 2018 at 23:11, Michael Zimmermann > > 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. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] reasoning beehind prohibiting VFP/NEON on AArch32
On 13 May 2018 at 11:48, Michael Zimmermann 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 > wrote: > >> On 12 May 2018 at 23:11, Michael Zimmermann > 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. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] reasoning beehind prohibiting VFP/NEON on AArch32
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 wrote: > On 12 May 2018 at 23:11, Michael Zimmermann 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. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] reasoning beehind prohibiting VFP/NEON on AArch32
On 12 May 2018 at 23:11, Michael Zimmermann 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. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
