From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Russ Anderson <rja@hpe.com>
Cc: Borislav Petkov <bp@alien8.de>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Matt Fleming <matt@codeblueprint.co.uk>,
Ard Biesheuvel <ardb@kernel.org>, Dave Young <dyoung@redhat.com>,
linux-efi <linux-efi@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
Dimitri Sivanich <dimitri.sivanich@hpe.com>,
Mike Travis <mike.travis@hpe.com>,
Hedi Berriche <hedi.berriche@hpe.com>
Subject: Re: [RFC PATCH] efi/x86: limit EFI old memory map to SGI UV1 machines
Date: Thu, 2 Jan 2020 17:52:39 +0100 [thread overview]
Message-ID: <CAKv+Gu86SaU+D8x2ScRXbTvR8aK23CfhAL=mkUNcn=9vrbgznw@mail.gmail.com> (raw)
In-Reply-To: <20200102164536.ks5dmtrbtl4i7rnt@hpe.com>
On Thu, 2 Jan 2020 at 17:45, Russ Anderson <rja@hpe.com> wrote:
>
> On Thu, Jan 02, 2020 at 04:04:39PM +0100, Ard Biesheuvel wrote:
> > On Thu, 2 Jan 2020 at 15:38, Russ Anderson <rja@hpe.com> wrote:
> > >
> > > On Tue, Dec 31, 2019 at 05:05:47PM +0100, Borislav Petkov wrote:
> > > > On Tue, Dec 31, 2019 at 12:13:18PM +0100, Ard Biesheuvel wrote:
> > > > > (adding Boris and Dave for the historical perspective)
> > > > >
> > > > > On Thu, 26 Dec 2019 at 10:55, Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > > >
> > > > > > We carry a quirk in the x86 EFI code to switch back to an older
> > > > > > method of mapping the EFI runtime services memory regions, because
> > > > > > it was deemed risky at the time to implement a new method without
> > > > > > providing a fallback to the old method in case problems arose.
> > > > > >
> > > > > > Such problems did arise, but they appear to be limited to SGI UV1
> > > > > > machines, and so these are the only ones for which the fallback gets
> > > > > > enabled automatically (via a DMI quirk). The fallback can be enabled
> > > > > > manually as well, by passing efi=old_map, but there is very little
> > > > > > evidence that suggests that this is something that is being relied
> > > > > > upon in the field.
> > > > > >
> > > > > > Given that UV1 support is not enabled by default by the distros
> > > > > > (Ubuntu, Fedora), there is no point in carrying this fallback code
> > > > > > all the time if there are no other users. So let's refactor it a bit
> > > > > > to make it depend on CONFIG_X86_UV, and remove the ability to enable
> > > > > > it by hand.
> > > > > >
> > > > > > Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
> > > > > > Cc: Mike Travis <mike.travis@hpe.com>
> > > > > > Cc: Hedi Berriche <hedi.berriche@hpe.com>
> > > > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > > > >
> > > > > Boris, since you were the one that added efi=old_map: do you know of
> > > > > any cases beyond SGI UV1 where it was actually needed? There is some
> > > > > mention of using it to work around transient breakage on 32-bit caused
> > > > > by your original changes, but other than that, Google doesn't seem to
> > > > > know about any cases where efi=old_map is being used to deal with
> > > > > actual firmware quirks.
> > >
> > > We (SGI -> HPE) have used the efi=old_map quirk to work around issues,
> > > including on the currently shipping HPE Superdome Flex (aka UV4).
> > >
> > > An example was working around an EFI locking issues when calling
> > > into BIOS, fixed by this commit.
> > >
> > > f331e766c4be ("x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls")
> > >
> > > We do not currently use the quirk, and nopefully never will need to
> > > use it again, but it has been used recently and are very glad Boris
> > > added it. I am hesitent to remove it because it has been used recently
> > > on currently shipping hardware.
> > >
> >
> > Thanks for the data point.
> >
> > So what about making it depend on CONFIG_X86_UV=y, would that still
> > work for you?
>
> I want to make sure my undestanding of what you are proposing
> is the same as what you are proposing.
>
What I am proposing is to document efi=old_map as only being available
on kernels built with CONFIG_X86_UV=y, and moving the code that
implements it into the UV support code.
> I will have some additional background information shortly.
>
Thanks, that is very helpful.
next prev parent reply other threads:[~2020-01-02 16:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-26 9:55 [RFC PATCH] efi/x86: limit EFI old memory map to SGI UV1 machines Ard Biesheuvel
2019-12-31 11:13 ` Ard Biesheuvel
2019-12-31 16:05 ` Borislav Petkov
2019-12-31 22:28 ` Matthew Garrett
2020-01-02 14:37 ` Russ Anderson
2020-01-02 15:04 ` Ard Biesheuvel
2020-01-02 15:39 ` Dimitri Sivanich
2020-01-02 16:45 ` Russ Anderson
2020-01-02 16:52 ` Ard Biesheuvel [this message]
2020-01-02 23:13 ` Russ Anderson
2020-01-03 8:14 ` Ard Biesheuvel
2020-01-06 5:01 ` Russ Anderson
[not found] ` <20200101030339.GA8856@dhcp-128-65.nay.redhat.com>
2020-01-01 3:07 ` Dave Young
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='CAKv+Gu86SaU+D8x2ScRXbTvR8aK23CfhAL=mkUNcn=9vrbgznw@mail.gmail.com' \
--to=ard.biesheuvel@linaro.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dimitri.sivanich@hpe.com \
--cc=dyoung@redhat.com \
--cc=hedi.berriche@hpe.com \
--cc=linux-efi@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mike.travis@hpe.com \
--cc=mjg59@srcf.ucam.org \
--cc=rja@hpe.com \
--cc=x86@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 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).