linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: olivier.martin@arm.com (Olivier Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/2] efi: preserve NEON registers on UEFI services calls
Date: Tue, 8 Jul 2014 16:33:32 +0100	[thread overview]
Message-ID: <005f01cf9ac1$f9f01460$edd03d20$@martin@arm.com> (raw)
In-Reply-To: <CAKv+Gu8yb=H2734e-Wai3npK_qwsq7SWHumn+1gjkmJhF-2QQA@mail.gmail.com>

It is correct the UEFI 2.4 spec says 'Floating point and SIMD instructions may be used'. And it is also correct these registers are not preserved in the current UEFI EDK2 implementation.
I will keep track in ARM UEFI todo list.

Acked-by: Olivier Martin <olivier.martin@arm.com>

Thanks Ard for your patch,
Olivier

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org]
> Sent: 01 July 2014 14:46
> To: Matt Fleming
> Cc: Matt Fleming; x86 at kernel.org; Catalin Marinas; linux-
> efi at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> hpa at zytor.com; Leif Lindholm; Roy Franz; msalter at redhat.com; Olivier
> Martin
> Subject: Re: [PATCH v2 0/2] efi: preserve NEON registers on UEFI
> services calls
> 
> On 1 July 2014 15:26, Matt Fleming <matt@console-pimps.org> wrote:
> > On Thu, 26 Jun, at 12:09:04PM, Ard Biesheuvel wrote:
> >> The current UEFI implementation for arm64 fails to preserve/restore
> the contents
> >> of the NEON register file, which may result in data corruption,
> especially now
> >> that those contents are lazily restored for user processes.
> >>
> >> This series proposes to fix this by wrapping all runtime services
> calls, and
> >> adding kernel_neon_begin()/kernel_neon_end() pairs to the wrappers.
> >>
> >> The first patch moves the existing x86 versions of those wrappers to
> generic
> >> code, so that the second patch can easily enable them by supplying a
> definition
> >> for efi_call_virt and adding a call to efi_native_runtime_setup().
> >>
> >> Changes since v1:
> >> - rename runtime.c -> runtime-wrappers.c
> >> - make build depend on new Kconfig symbol EFI_RUNTIME_WRAPPERS to
> fix ia64
> >>   breakage
> >> - remove default #defines for efi_call_virt()/__efi_call_virt(),
> they are not
> >>   needed anymore now that it is built conditionally
> >> - add references to applicable UEFI/AAPCS spec sections
> >>
> >> Ard Biesheuvel (2):
> >>   efi/x86: move UEFI Runtime Services wrappers to generic code
> >>   efi/arm64: preserve FP/SIMD registers on UEFI runtime services
> calls
> >
> > Thanks Ard. These patches look OK to me, and I've now pulled them
> into
> > my 'next' branch.
> >
> > It'd be nice if we could get some ACKs from other people since this
> is
> > an ABI issue.
> 
> Yes, they have been awfully quiet, haven't they?
> 
> At least Roy has volunteered to get involved in the USWG to get the
> spec clarified.
> 
> @Leif, Catalin, Olivier: care to chime in?
> 
> --
> Ard.

      reply	other threads:[~2014-07-08 15:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-26 10:09 [PATCH v2 0/2] efi: preserve NEON registers on UEFI services calls Ard Biesheuvel
2014-06-26 10:09 ` [PATCH v2 1/2] efi/x86: move UEFI Runtime Services wrappers to generic code Ard Biesheuvel
2014-07-01 13:30   ` Matt Fleming
2014-07-01 13:35     ` Ard Biesheuvel
2014-07-01 13:48       ` Matt Fleming
2014-06-26 10:09 ` [PATCH v2 2/2] efi/arm64: preserve FP/SIMD registers on UEFI runtime services calls Ard Biesheuvel
2014-07-04 15:45   ` Catalin Marinas
2014-07-04 15:51     ` Ard Biesheuvel
2014-07-04 16:59       ` Catalin Marinas
2014-07-04 17:15         ` Ard Biesheuvel
2014-06-26 13:58 ` [PATCH v2 0/2] efi: preserve NEON registers on UEFI " Mark Salter
2014-06-26 14:22   ` Ard Biesheuvel
2014-07-01 13:26 ` Matt Fleming
2014-07-01 13:46   ` Ard Biesheuvel
2014-07-08 15:33     ` Olivier Martin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='005f01cf9ac1$f9f01460$edd03d20$@martin@arm.com' \
    --to=olivier.martin@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).