From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::22e; helo=mail-io0-x22e.google.com; envelope-from=sigmaepsilon92@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 15A102063D75D for ; Sun, 13 May 2018 05:49:57 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id e78-v6so12132350iod.0 for ; Sun, 13 May 2018 05:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+9ktg+mmGHAUGWxyeaP0B3TdIcV8PJ+FtPREmuDJlqs=; b=tOSdG0aHGOpfxpijydFegW2oNTe0DSt/uFTiXDFXtx/xumVn2yf3UtB3BR7JVS3UxE wZgasVJ/C1IFEcQ6XAuS7/n9VNRKPgKpEu/UWa6Nvmie562ssvxtzOGmlBogZvARFrAH qwpfVx4tZLjarK+4vsoklBn+XituhF0v/IZjLyvuz+6EAGnR+Rz5qnuRtNPPF20IZa8q Zd9IN93p2/I31aNwqk1SO9VAoMik2nwSPoU0TYjvQwBLz4JixPiFwC9+S9N5WQEOlcIP xlKEMshCCliIlflYxjX+Jrcqo+ObNbJ2GXcJ3THjYnpheXnWIDjtdc00qV73gEPmYy+J 3bKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+9ktg+mmGHAUGWxyeaP0B3TdIcV8PJ+FtPREmuDJlqs=; b=XSQ+OYHxf9cgoVdjMAKTdRgqyZZARDuWfWRkuWe271gmt8U64UxLVmmhDE5/iSgDk6 BeYreMwdOZhRgxbs13C31ZJ+Rlh7Mgbu2+px50KBCq1y4dgl3b08CpKrmRDDJHB4bq7N vSwpTlTKN3v1TAiDJ5yTw4g7RL4Y+dOAIaM/qc5iA5pBuDNIPBELbBB4FyG7BMjq3Lrv qGXEg0tGL80KVOIRwzY2PSkXgf8C5lmlkCdz598dtRfEk5hj8o2zyzHYYcyz64cutw5I uy+1in0lXDI9SovCpt0K8hicmop8zYUe+/RIZto/vRB4AhsHJ5xW78Md7T8xKV8Keo9Z QvLw== X-Gm-Message-State: ALKqPwdoFx8vKt7e1RqX8Y1smgjmYgNB0h7OTL9hhSXtVlQqQhC5kDxC AQJAdredtJy0GhbZjTid9mYlWj9kf/vEFxug/4c= X-Google-Smtp-Source: AB8JxZo21PIawLhLBMGIx9q6aV9/A/f8Q1+mi7aWueqt/RV5xCmbhGyzUyZT33tKIDyQeeTiOjB0iThmUq7zA7ru7P0= X-Received: by 2002:a6b:8544:: with SMTP id h65-v6mr6119360iod.271.1526215796919; Sun, 13 May 2018 05:49:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Zimmermann Date: Sun, 13 May 2018 14:49:45 +0200 Message-ID: To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Leif Lindholm Subject: Re: reasoning beehind prohibiting VFP/NEON on AArch32 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2018 12:49:58 -0000 Content-Type: text/plain; charset="UTF-8" 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.biesheuvel@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.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.