From: Nathan Chancellor <nathan@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Johan Hovold <johan+linaro@kernel.org>,
Maximilian Luz <luzmaximilian@gmail.com>,
Steev Klimaszewski <steev@kali.org>,
Shawn Guo <shawn.guo@linaro.org>
Subject: Re: [RFT PATCH 0/2] arm64: efi: Call SetVaMap() with a 1:1 mapping
Date: Tue, 17 Jan 2023 10:30:19 -0700 [thread overview]
Message-ID: <Y8bbK30nptwHKn88@dev-arch.thelio-3990X> (raw)
In-Reply-To: <CAMj1kXHbWwtxb8dL1G8OG4evTg448Xv_DZ_pi8rNF+oVmdtx4g@mail.gmail.com>
On Tue, Jan 17, 2023 at 04:20:09PM +0100, Ard Biesheuvel wrote:
> On Tue, 17 Jan 2023 at 15:27, Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > Linux on arm64 is now in the same boat as x86, where supporting laptops
> > that were built to run Windows and never tested beyond what is required
> > for the Windows Logo certification need workarounds for all kinds of
> > bizarre behaviors.
> >
> > On Snapdragon laptops, we cannot call SetVirtualAddressMap() from the
> > stub, because the firmware will crash while trying to access memory via
> > the virtual addresses being installed, which is explicitly unsupported
> > by the EFI spec.
> >
> > However, not calling SetVirtualAddressMap() results in other problems:
> > on Ampere Altra, it causes SetTime() to crash. On Surface and Flex5g
> > Windows-on-ARM laptops, it causes ResetSystem() to crash.
> >
> > So let's try to work around this while not making too much of a mess.
> >
> > First of all, install a 1:1 mapping instead of avoiding SetVaMap()
> > altogether - from the EFI spec pov, this should amount to the same
> > thing.
> >
> > Then, given that we already use a SMBIOS based hack for Altra to force
> > the use of SetVirtualAddressMap(), let's check for Surface systems in
> > the same way.
> >
> > Please test, and please report the SMBIOS type 1 family field for which
> > this workaround is needed.
> >
> > Also, note that these changes will not make a difference if the
> > EFI_RT_PROPERTIES_TABLE lists SetVirtualAddressMap() as not implemented.
> >
> > Nathan, I would appreciate it if you could give this a spin on your
> > Altra box (only patch #1 should make a difference), and for good
> > measure, double check that hwclock still works as it should.
> >
> > Cc: Johan Hovold <johan+linaro@kernel.org>
> > Cc: Maximilian Luz <luzmaximilian@gmail.com>
> > Cc: Nathan Chancellor <nathan@kernel.org>
> > Cc: Steev Klimaszewski <steev@kali.org>
> > Cc: Shawn Guo <shawn.guo@linaro.org>
> >
> > Ard Biesheuvel (2):
> > arm64: efi: Prefer a flat virtual mapping of the runtime services
> > arm64: efi: Force use of SetVirtualAddressMap() on MS Surface
> >
>
> Bah this does not even work on Yoga C630, so this is not going to help us.
>
> If we want ResetSystem() on these machines, we'll have to retain other
> memory ranges and map the in the EFI runtime map. Yuck.
>
> Nathan - still interested in whether patch #1 works on Altra,
I applied patch 1 on top of commit 6e50979a9c87 ("Merge tag
'mm-hotfixes-stable-2023-01-16-15-23' of
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm") in Linus' tree
and everything still appears to be okay with hwclock. If there is any
more specific testing that I should do, please let me know. Feel free to
add
Tested-by: Nathan Chancellor <nathan@kernel.org>
to patch 1 in future revisions, and I am happy to test anything else
that you might need in this series or future ones.
Mainline:
# uname -mr
6.2.0-rc4-00031-g6e50979a9c87 aarch64
# hwclock
2023-01-17 09:04:58.845411-07:00
Patch:
# uname -mr
6.2.0-rc4-00032-g20165e83052e aarch64
# hwclock
2023-01-17 10:25:38.843788-07:00
Cheers,
Nathan
_______________________________________________
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:[~2023-01-17 17:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 14:27 [RFT PATCH 0/2] arm64: efi: Call SetVaMap() with a 1:1 mapping Ard Biesheuvel
2023-01-17 14:27 ` [RFT PATCH 1/2] arm64: efi: Prefer a flat virtual mapping of the runtime services Ard Biesheuvel
2023-01-17 14:27 ` [RFT PATCH 2/2] arm64: efi: Force use of SetVirtualAddressMap() on MS Surface Ard Biesheuvel
2023-01-17 15:20 ` [RFT PATCH 0/2] arm64: efi: Call SetVaMap() with a 1:1 mapping Ard Biesheuvel
2023-01-17 17:30 ` Nathan Chancellor [this message]
2023-01-18 7:56 ` Ard Biesheuvel
2023-01-18 15:26 ` Nathan Chancellor
2023-01-18 15:33 ` Ard Biesheuvel
2023-02-27 19:43 ` Darren Hart
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=Y8bbK30nptwHKn88@dev-arch.thelio-3990X \
--to=nathan@kernel.org \
--cc=ardb@kernel.org \
--cc=johan+linaro@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=luzmaximilian@gmail.com \
--cc=shawn.guo@linaro.org \
--cc=steev@kali.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