Hi Ard,
-----Original Message----- From: Ard Biesheuvel ardb@kernel.org Sent: Thursday, February 9, 2023 11:31 PM To: Justin He Justin.He@arm.com Cc: Darren Hart darren@os.amperecomputing.com; LKML linux-kernel@vger.kernel.org; stable@vger.kernel.org; linux-efi@vger.kernel.org; Alexandru Elisei alexandru.elisei@gmail.com; nd nd@arm.com; Nathan Chancellor nathan@kernel.org Subject: Re: [PATCH v2] arm64: efi: Force the use of SetVirtualAddressMap() on eMAG and Altra Max machines
(cc Nathan, another happy Ampere customer)
On Thu, 9 Feb 2023 at 05:26, Justin He Justin.He@arm.com wrote:
-----Original Message----- From: Darren Hart darren@os.amperecomputing.com Sent: Thursday, February 9, 2023 8:28 AM To: LKML linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org; linux-efi@vger.kernel.org; Alexandru Elisei alexandru.elisei@gmail.com; Justin He Justin.He@arm.com; Huacai Chen chenhuacai@kernel.org; Jason A. Donenfeld Jason@zx2c4.com; Ard Biesheuvel ardb@kernel.org Subject: [PATCH v2] arm64: efi: Force the use of SetVirtualAddressMap() on eMAG and Altra Max machines
Commit 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") identifies the Altra family via the family field in the type#1 SMBIOS record. eMAG and Altra Max machines are similarly affected but not detected with the strict
strcmp test.
The type1_family smbios string is not an entirely reliable means of identifying systems with this issue as OEMs can, and do, use their own strings for these fields. However, until we have a better solution, capture the bulk of these systems by adding strcmp matching for
"eMAG"
and "Altra Max".
Fixes: 550b33cfd445 ("arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines") Cc: stable@vger.kernel.org # 6.1.x Cc: linux-efi@vger.kernel.org Cc: Alexandru Elisei alexandru.elisei@gmail.com Cc: Justin He Justin.He@arm.com Cc: Huacai Chen chenhuacai@kernel.org Cc: "Jason A. Donenfeld" Jason@zx2c4.com Cc: Ard Biesheuvel ardb@kernel.org Signed-off-by: Darren Hart darren@os.amperecomputing.com
Tested-by: justin.he@arm.com
V1 -> V2: include eMAG
drivers/firmware/efi/libstub/arm64.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/efi/libstub/arm64.c b/drivers/firmware/efi/libstub/arm64.c index ff2d18c42ee7..4501652e11ab 100644 --- a/drivers/firmware/efi/libstub/arm64.c +++ b/drivers/firmware/efi/libstub/arm64.c @@ -19,10 +19,13 @@ static bool system_needs_vamap(void) const u8 *type1_family = efi_get_smbios_string(1, family);
/*
* Ampere Altra machines crash in SetTime() ifSetVirtualAddressMap()
* has not been called prior.
* Ampere eMAG, Altra, and Altra Max machines crash in SetTime()if
* SetVirtualAddressMap() has not been called prior. */
if (!type1_family || strcmp(type1_family, "Altra"))
if (!type1_family || (strcmp(type1_family, "eMAG") &&strcmp(type1_family, "Altra") &&strcmp(type1_family, "Altra Max")))In terms of resolving the boot hang issue, it looks good to me. And I've verified the "eMAG" part check. So please feel free to add: Tested-by: Justin He justin.he@arm.com
Thanks. I've queued this up now.
But I have some other concerns:
- On an Altra server, the type1_family returns "Server". I don't know
whether it is a smbios or server firmware bug.
This is not really a bug. OEMs are free to put whatever they want into those fields, although that is a great example of a sloppy vendor that just puts random junk in there.
We could plumb in the type 4 smbios record too, and check the version for *Altra* - however, it would be nice to get an idea of how many more we will end up needing to handle here.
Also, is anyone looking to get this fixed? There is Altra code in the public EDK2 repo, but it is very hard to get someone to care about these things, and fix their firmware.
- On an eMAG server, I once successfully run efibootmgr -t 10 to call
the Set_variable rts, but currently I always met the error, even with above
patch:
# efibootmgr -t 9; efibootmgr -t 5; Could not set Timeout: Input/output error Could not set Timeout: Input/output error
Did this work before? Can you bisect?
Yes, it worked before, as the log I attached in previous thread. That kernel is v5.19+. But very strange, now I tried different kernel (v6.x, v5.19,v4.19), It didn't work now.
Bisect doesn’t help in this case.
-- Cheers, Justin (Jia He)