[RFT PATCH 0/2] arm64: efi: Call SetVaMap() with a 1:1 mapping

[Nathan Chancellor]

On Wed, Jan 18, 2023 at 08:56:54AM +0100, Ard Biesheuvel wrote:
> On Tue, 17 Jan 2023 at 18:30, Nathan Chancellor <nathan at kernel.org> wrote:
> >
> > On Tue, Jan 17, 2023 at 04:20:09PM +0100, Ard Biesheuvel wrote:
> > > On Tue, 17 Jan 2023 at 15:27, Ard Biesheuvel <ardb at 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 at kernel.org>
> > > > Cc: Maximilian Luz <luzmaximilian at gmail.com>
> > > > Cc: Nathan Chancellor <nathan at kernel.org>
> > > > Cc: Steev Klimaszewski <steev at kali.org>
> > > > Cc: Shawn Guo <shawn.guo at 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 at 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
> >
> 
> Thanks Nathan,
> 
> Forgot to mention, though: it is SetTime() not GetTime() that is
> problematic on this platform. Could you please double check whether
> setting the RTC using hwclock works too?

Ah, okay, makes sense! As far as I can tell, that works too.

Mainline:

# uname -mr
6.2.0-rc4-00031-g6e50979a9c87 aarch64

# hwclock --systohc

# echo $status
0

Patch:

# uname -mr
6.2.0-rc4-00032-g20165e83052e aarch64

# hwclock --systohc

# echo $status
0

Cheers,
Nathan