From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
will@kernel.org, linux-efi@vger.kernel.org, maz@kernel.org
Subject: Re: [PATCH] arm64: efi: Recover from synchronous exceptions occurring in firmware
Date: Wed, 2 Nov 2022 13:41:25 +0000 [thread overview]
Message-ID: <Y2JzhYP8eBkgiXta@arm.com> (raw)
In-Reply-To: <CAMj1kXFcAFEKTuaF5RfMrktoT0+w_E80tDiFoDWA-7vezCxPdA@mail.gmail.com>
On Wed, Nov 02, 2022 at 10:08:28AM +0100, Ard Biesheuvel wrote:
> On Fri, 28 Oct 2022 at 17:01, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > Unlike x86, which has machinery to deal with page faults that occur
> > during the execution of EFI runtime services, arm64 has nothing like
> > that, and a synchronous exception raised by firmware code brings down
> > the whole system.
> >
> > With more EFI based systems appearing that were not built to run Linux
> > (such as the Windows-on-ARM laptops based on Qualcomm SOCs), as well as
> > the introduction of PRM (platform specific firmware routines that are
> > callable just like EFI runtime services), we are more likely to run into
> > issues of this sort, and it is much more likely that we can identify and
> > work around such issues if they don't bring down the system entirely.
> >
> > Since we already use a EFI runtime services call wrapper in assembler,
> > we can quite easily add some code that captures the execution state at
> > the point where the call is made, allowing us to revert to this state
> > and proceed execution if the call triggered a synchronous exception.
> >
> > Given that the kernel and the firmware don't share any data structures
> > that could end up in an indeterminate state, we can happily continue
> > running, as long as we mark the EFI runtime services as unavailable from
> > that point on.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>
> Does anyone mind if I take this via the EFI tree for v6.1?
No, feel free to take it.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com,
will@kernel.org, linux-efi@vger.kernel.org, maz@kernel.org
Subject: Re: [PATCH] arm64: efi: Recover from synchronous exceptions occurring in firmware
Date: Wed, 2 Nov 2022 13:41:25 +0000 [thread overview]
Message-ID: <Y2JzhYP8eBkgiXta@arm.com> (raw)
In-Reply-To: <CAMj1kXFcAFEKTuaF5RfMrktoT0+w_E80tDiFoDWA-7vezCxPdA@mail.gmail.com>
On Wed, Nov 02, 2022 at 10:08:28AM +0100, Ard Biesheuvel wrote:
> On Fri, 28 Oct 2022 at 17:01, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > Unlike x86, which has machinery to deal with page faults that occur
> > during the execution of EFI runtime services, arm64 has nothing like
> > that, and a synchronous exception raised by firmware code brings down
> > the whole system.
> >
> > With more EFI based systems appearing that were not built to run Linux
> > (such as the Windows-on-ARM laptops based on Qualcomm SOCs), as well as
> > the introduction of PRM (platform specific firmware routines that are
> > callable just like EFI runtime services), we are more likely to run into
> > issues of this sort, and it is much more likely that we can identify and
> > work around such issues if they don't bring down the system entirely.
> >
> > Since we already use a EFI runtime services call wrapper in assembler,
> > we can quite easily add some code that captures the execution state at
> > the point where the call is made, allowing us to revert to this state
> > and proceed execution if the call triggered a synchronous exception.
> >
> > Given that the kernel and the firmware don't share any data structures
> > that could end up in an indeterminate state, we can happily continue
> > running, as long as we mark the EFI runtime services as unavailable from
> > that point on.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>
> Does anyone mind if I take this via the EFI tree for v6.1?
No, feel free to take it.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-11-02 13:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 15:01 [PATCH] arm64: efi: Recover from synchronous exceptions occurring in firmware Ard Biesheuvel
2022-10-28 15:01 ` Ard Biesheuvel
2022-11-02 9:08 ` Ard Biesheuvel
2022-11-02 9:08 ` Ard Biesheuvel
2022-11-02 13:41 ` Catalin Marinas [this message]
2022-11-02 13:41 ` Catalin Marinas
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=Y2JzhYP8eBkgiXta@arm.com \
--to=catalin.marinas@arm.com \
--cc=ardb@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.