Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <CAEQFVGZ=6K8wudbS--3z+JpKTsL_dfM-8Co7NwViRo0i3t2EZg@mail.gmail.com>
 <Ym2qdHAB6BMMlegB@thelio-3990X> <CAEQFVGZB6eAetmt1kk+TYbGxpfrDut37DEO_-1HECqM6FEERww@mail.gmail.com>
 <CAEQFVGby3Q1mf1GGJwkFyAgaq38NvVAMx6tQM+9LO+HE8Z8Z8A@mail.gmail.com>
 <YnhbOpXHT8k+g9Qu@dev-arch.thelio-3990X> <CAEQFVGYSV=boBYGHfJLis8ayftzNPJy1UYgeEEQLuNb0hSfhjg@mail.gmail.com>
 <CAKwvOd=c=9xbzg0CjGxNnHtu3BOatWpe0gYQU7TWw0rkjwCCxA@mail.gmail.com>
In-Reply-To: <CAKwvOd=c=9xbzg0CjGxNnHtu3BOatWpe0gYQU7TWw0rkjwCCxA@mail.gmail.com>
From:   Mauro Rossi <issor.oruam@gmail.com>
Date:   Wed, 1 Jun 2022 14:57:34 +0200
Message-ID: <CAEQFVGYOkTi4oNSnfyN48Re_4uhQqPF81+M7Xd5VJ0+tETwSbA@mail.gmail.com>
Subject: Re: arch/x86/entry/entry: RFC on recent kernels building error with
 llvm 11.0.2 internal assembler
To:     Nick Desaulniers <ndesaulniers@google.com>
Cc:     Nathan Chancellor <nathan@kernel.org>, luto@kernel.org,
        Chih-Wei Huang <cwhuang@android-x86.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        clang-built-linux <llvm@lists.linux.dev>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Jun 1, 2022 at 12:09 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Sun, May 29, 2022 at 10:52 AM Mauro Rossi <issor.oruam@gmail.com> wrote:
> >
> >
> >
> > On Mon, May 9, 2022 at 2:07 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >>
> >> On Sat, May 07, 2022 at 02:19:00PM +0200, Mauro Rossi wrote:
> >> > > > Alternatively, you could apply the hack that Nick inserted into Android
> >> > > > for this issue if upgrading your toolchain or turning off the integrated
> >> > > > assembler is not possible:
> >> > > >
> >> > > > https://android.googlesource.com/kernel/common/+/e58f084735b8abf744d61083b92172ee23d45aae
> >> > > >
> >> > > > I really do not mean to sound dismissive or rude, I apologize if it
> >> > > > comes off that way, but we have worked quite hard to avoid inserting
> >> > > > unnecessary workarounds, as they are ultimately technical debt that can
> >> > > > be hard to manage over the long term.
> >> > > >
> >> > > > Cheers,
> >> > > > Nathan
> >> > >
> >> > > Thanks a lot Nathan
> >> > >
> >> > > It is definitely the clang version 11.0.x which is not updated in aosp
> >> > > Android 11 production tags
> >> > >
> >> > > I will use Nick's workaround which works since only lsl %rax, %rax is
> >> > > currently happening
> >> > >
> >> > > Many thanks, problem solved
> >> >
> >> > Hello,
> >> > I'm back again because I was assuming that Nick's workaround was working ok,
> >> > but I have found that ARCH=x86_64 i.e. 64bit built kernel is causing
> >> > an immediate hard reboot at initrd execution,
> >> > just after hitting [ENTER] at grub/efi menu.
> >>
> >> It looks like there was a follow up fix for that workaround, maybe that
> >> resolves this issue as well?
> >>
> >> https://android.googlesource.com/kernel/common/+/cc7f7a84191f5defc2ea4633eeea4acb4486b549
> >>
> >> > ARCh=x86 i.e. 32bit kernel binary is not affected, but is Nick's
> >> > workaround targeting 32 bit kernel builds?
> >>
> >> No, the file that the build error originates from (entry_64.S) is only
> >> built on x86_64.
> >>
> >> > How do aosp android-mailine kernels avoid this instantaneous hard reboot issue?
> >>
> >> That hack was reverted once the toolchain was upgraded:
> >>
> >> https://android.googlesource.com/kernel/common/+/ff0216d09fd31802537f2d1702ec2f3e9be73aa3
> >> https://android.googlesource.com/kernel/common/+/3c2c8d8f7f2639e319212d10cb8df5bd13098dae
> >>
> >> Cheers,
> >> Nathan
> >
> >
> > Hello,
> >
> > sorry i still have the issue when building with hack "ANDROID: x86: entry: work around LLVM_IAS=1 bug in LSL"
> > I'd just like to understand why I get instant reboot in 64bit kernel built with LLVM_IAS=1
>
> As Nathan noted, I messed up the commit "ANDROID: x86: entry: work
> around LLVM_IAS=1 bug in LSL". Please see:
> https://android-review.googlesource.com/c/kernel/common/+/1521061
> https://android-review.googlesource.com/c/kernel/common/+/1560152/
>
> If you're using an older toolchain, you'll need just the first. If
> you're using a newer toolchain, you'll need BOTH (or none, including
> dropping "ANDROID: x86: entry: work around LLVM_IAS=1 bug in LSL").

Thanks Nick,

I had already applied the squashed commit composed of  "ANDROID: x86:
entry: work around LLVM_IAS=1 bug in LSL" (the one using .quad) and
"ANDROID: x86: entry: fix LSL open coding", so I have already:

.macro LOAD_CPU_AND_NODE_SEG_LIMIT reg:req
movq $__CPUNODE_SEG, \reg
+#ifdef __clang__
+.long 0xc0030f48
+#else
lsl \reg, \reg
+#endif
.endm


So in principle my kernel image should boot when built with LLVM_IAS=1
but to my surprise all my systems (Sony VAIO i7, Intel NUC DN2820FYKH
with Celeron D2830, Athlon 200GE) are affected by hard reboot when
executing the kernel image

I'm trying to understand how to build (and boot) with LLVM_IAS=1 and
using clang 11.0.2 shipped with AOSP Android 11

>
> >
> > I searched for the places where #include "calling.h" is used
> >
> > utente@utente-3TB:~/r-x86_kernel/kernel$ grep -r \#include\ \"calling
> > arch/x86/entry/thunk_64.S:#include "calling.h"
> > arch/x86/entry/entry_32.S:#include "calling.h"
> > arch/x86/entry/entry_64_compat.S:#include "calling.h"
> > arch/x86/entry/entry_64.S:#include "calling.h"
> >
> > Probably the hardcoding done in the hack is impacting some other asm target built in 64 bit kernel and causes a wrong X86 instruction , is there a way to refine the #if to avoid that problem while still building with LLVM_IAS=1 ?
> >
> > Thanks for the info
> > Mauro
> >
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers