[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <39617a3e-c476-abac-8425-bbcece769cdb@loongson.cn>
Date: Sat, 22 Nov 2025 19:04:33 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Huacai Chen <chenhuacai@...nel.org>, Will Deacon <will@...nel.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>,
Catalin Marinas <catalin.marinas@....com>, Paul Walmsley <pjw@...nel.org>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
"Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>,
Ard Biesheuvel <ardb@...nel.org>, loongarch@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-riscv@...ts.infradead.org,
linux-efi@...r.kernel.org, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, Nathan Chancellor <nathan@...nel.org>
Subject: Re: [PATCH v2] efistub: Only link libstub to final vmlinux
Cc: Nathan Chancellor <nathan@...nel.org>
Hi all,
On 11/21/25 22:36, Huacai Chen wrote:
> On Mon, Nov 17, 2025 at 7:33 PM Will Deacon <will@...nel.org> wrote:
>>
>> On Sat, Nov 15, 2025 at 11:16:42AM +0800, Huacai Chen wrote:
>>> On Wed, Nov 12, 2025 at 2:00 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>>>>
>>>> On Mon, Nov 10, 2025 at 03:00:00PM +0800, Huacai Chen wrote:
>>>>> On Mon, Nov 10, 2025 at 9:19 AM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
>>>>>> If I understand correctly, I should modify this patch to remove the
>>>>>> changes of arm and riscv for now, do the changes only when there is
>>>>>> a real problem or requirement some day, right? If no more comments,
>>>>>> I will send v3 later.
>>>>>
>>>>> Now everyone involved agrees that the efistub code is correct, so the
>>>>> proper solution is to fix the compiler.
>>>>
>>>> Hm? I don't see how it's a compiler bug. It's really just an objtool
>>>> limitation.
>>>>
>>>>> Changing efistub code and changing objtool (ignore __efistub prefix)
>>>>> are both workarounds, but I think changing objtool is a little more
>>>>> reasonable. Maybe Josh has different ideas?
>>>>
>>>> I thought the conversation had converged on what Tiezhu mentioned above,
>>>> which is to skip objtool on libstub for loongarch, but leave the other
>>>> arches alone. That way objtool behavior is consistent between loongarch
>>>> and x86, and objtool doesn't need to ignore any prefixes.
>>>>
>>>> So basically, the v2 patch minus the arm64/riscv changes.
>>>
>>> Hi, ARM64 and RISC-V maintainers,
>>>
>>> Would you mind that this patch modifies the three architectures
>>> together (they are exactly the same style now)?
>>>
>>> Madhavan is the author of ARM64's objtool, I think your opinion is
>>> also very important.
>>
>> arm64 doesn't (yet) use objtool.
>>
>> I defer to Ard on anything relating to the arm64 efistub. Reading the
>> start of this thread, it doesn't look like he's convinced and I'm not
>> surprised if it's purely an issue with objtool.
> OK, I know, but I have a concern.
>
> Ard said that he is reluctant to make changes to accommodate a flawed
> build time tool and there may be regression risk.
>
> So, I'm also reluctant and don't want LoongArch to meet regression
> risk. If one day LoongArch has a regression, we probably need another
> workaround to "fix" this workaround. But if these three architectures
> change in the same way, we may have a chance to solve some fundamental
> problems...
IIUC, Josh do not like to ignore these EFISTUB functions in
validate_branch() of objtool, Huacai do not like to only link
libstub to vmlinux only for LoongArch.
It seems that there is only one way to fix or workaround this
problem, remove the attribute __noreturn for real_kernel_entry()
and then make efi_boot_kernel() ends with a return instruction [1]
or an unconditional jump instruction [2] that only touches
drivers/firmware/efi/libstub/loongarch.c.
Since this is a issue only for LoongArch by now, what do you
think of this minimal change only for LoongArch libstub code?
Using "return EFI_LOAD_ERROR" [1] or "while (1)" [2]?
Maybe this is the simple and direct way for this special issue
only on LoongArch so far. If not, any other suggestions?
On the other hand, is it possible to add KBUILD_VMLINUX_LIBS_FINAL
and then use it only for LoongArch first [3]? Any potential risks?
What is the next step?
[1]
https://lore.kernel.org/loongarch/CAMj1kXH-rK0bRyHXdJ-crAyMyvJHApH0WR7_8Qd8vrSPBLK+yg@mail.gmail.com/
[2]
https://lore.kernel.org/loongarch/20250826064631.9617-2-yangtiezhu@loongson.cn/
[3] https://lore.kernel.org/loongarch/20251122000101.GA1996391@ax162/
Thanks,
Tiezhu
Powered by blists - more mailing lists