summaryrefslogtreecommitdiffstats
path: root/drivers/block
diff options
context:
space:
mode:
authorArd Biesheuvel <ardb@kernel.org>2022-11-10 10:36:20 +0100
committerArd Biesheuvel <ardb@kernel.org>2022-11-10 23:14:14 +0100
commit550b33cfd445296868a478e8413ffb2e963eed32 (patch)
tree20293f6a8aa8916a87ef2a433a1a7fc4c3044556 /drivers/block
parentarm64: efi: Recover from synchronous exceptions occurring in firmware (diff)
downloadlinux-550b33cfd445296868a478e8413ffb2e963eed32.tar.xz
linux-550b33cfd445296868a478e8413ffb2e963eed32.zip
arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines
Ampere Altra machines are reported to misbehave when the SetTime() EFI runtime service is called after ExitBootServices() but before calling SetVirtualAddressMap(). Given that the latter is horrid, pointless and explicitly documented as optional by the EFI spec, we no longer invoke it at boot if the configured size of the VA space guarantees that the EFI runtime memory regions can remain mapped 1:1 like they are at boot time. On Ampere Altra machines, this results in SetTime() calls issued by the rtc-efi driver triggering synchronous exceptions during boot. We can now recover from those without bringing down the system entirely, due to commit 23715a26c8d81291 ("arm64: efi: Recover from synchronous exceptions occurring in firmware"). However, it would be better to avoid the issue entirely, given that the firmware appears to remain in a funny state after this. So attempt to identify these machines based on the 'family' field in the type #1 SMBIOS record, and call SetVirtualAddressMap() unconditionally in that case. Tested-by: Alexandru Elisei <alexandru.elisei@gmail.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Diffstat (limited to 'drivers/block')
0 files changed, 0 insertions, 0 deletions