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 <[email protected]> wrote: > On 13 May 2018 at 12:58, Michael Zimmermann <[email protected]> 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 < [email protected]> > > wrote: > > > >> On 13 May 2018 at 11:48, Michael Zimmermann <[email protected]> > > 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 < > > [email protected]> > >> > wrote: > >> > > >> >> On 12 May 2018 at 23:11, Michael Zimmermann < [email protected]> > >> > 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 [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
