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::229; helo=mail-io0-x229.google.com; envelope-from=sigmaepsilon92@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 2DFA720961825 for ; Sun, 13 May 2018 03:59:01 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id a10-v6so11957209ioc.9 for ; Sun, 13 May 2018 03:59:01 -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=YIRNyj0ZKO/LIPtk8flYWfqzFJacRda+EGeOxH01lZI=; b=c+Ao55VU8Zmy7+q++sYqfGhpsBSp6tBFvT6vdDRSXc3LLACqjcjfNhrChNPI84AvPk eOL1eyc8f+3oPain25RSXJqYIUPqJC2oIRzz+rjbmzw2NJ4fpE/3JFUcRUTXorFI3UlH iCPxQU6kr8L2VwGQalu824XA6e2mTH9eA3qhtabHyt9C/QmiosAQdpalISU5GD8RZw3c IVLkm2BedvtZIlU8g0jcv2H2XTCvhsMdy8/UAq20T++w2F5TIeJveOy2nL9ByGOZ+zDl NPO7FXROZOyrOfErdPOKqsz6d1Xf6WK8Og5O3xUZzYSO5x0urfka8SiYaOUkWdjDyB4E tYLw== 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=YIRNyj0ZKO/LIPtk8flYWfqzFJacRda+EGeOxH01lZI=; b=EugR0CRHh1/zVPdDYMb23g7KHjHWkUzCPqyehvfKjYgAbN65yWdygKn4RU10eeRcdv 7D+Bbm0LIXqEOpCgLAnxFlWqyaBffnVIG0v6wg7TTVujWiNeylW6s7EyJ85QsNpDemBQ PRKRHey79ksppheqNDTfA9gnQWdp1B0JsD8+3vairTRKeTKG3cRm/RYdnVEO+ZJqMrWR 2bNYOhCdTutRrf2YpyDNASXG3OTUrBlvHD2OW/guX9m2LQvRAwVhK1NNECkRQ7tXuRGG ir3JMcqFVsRH4U0nzD9xa+KQwanHQuidqbb9Gqh9/HwBGrYlDgu0CatduQrmwYdKuw9Z SIbA== X-Gm-Message-State: ALKqPwe7YReX/dK2OZ8EZUflK8Glg+mwVEs6pHGT2UfNEVKIq3ZvJrZl 8ZWMm65mkZStZfDhA5Bpn54A3N+L4JLfbJHpSAysJEW7 X-Google-Smtp-Source: AB8JxZp1lszG32fb5GCJ8kyqzxIGI8IQnvi476j5iaNwKrel9ogfuya9oLVSWpl5u8qUfznYEvm2fEl4fFABbJrHjeU= X-Received: by 2002:a6b:afe4:: with SMTP id p97-v6mr6058865ioo.257.1526209141191; Sun, 13 May 2018 03:59:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Zimmermann Date: Sun, 13 May 2018 12:58:49 +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 10:59:02 -0000 Content-Type: text/plain; charset="UTF-8" > 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.biesheuvel@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.